[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#203421: marked as done (kmahjongg: Kmahjongg should not redraw the complete field at every click)



Your message dated Sat, 3 Mar 2007 02:40:47 +0100
with message-id <20070303014047.GA13570@pryan.sytes.net>
and subject line kmahjongg: Kmahjongg should not redraw the complete field at every click
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: kmahjongg
Version: 4:3.1.2-2
Severity: minor
Tags: upstream

Hi,

I'm currently playing Kmahjongg over a 10 MBit half duplex line. Every
time I click at a piece it takes some seconds until the screen is
updated. I think it is because the complete client area of Kmahjongg is
calculated and then drawn on the screen.

For me, it would be better if only the area that really changed would be
updated, as this would save a lot of bandwidth :)

Suggestion: You could always have a memory bitmap of the current screen
and then calculate the new screen as another memory bitmap. Then you
could check which lines are different, and only make these lines
candidates for repainting. Then, for every line you could calculate the
interval that actually changed and then paint that interval.

If that algorithm is too slow for normal viewing (local, with graphics
accelerator), you could add a configuration option to switch between
these algorithms.

Roland

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux pc-debian 2.4.21-3-k7 #1 Sun Jul 20 19:23:36 EST 2003 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages kmahjongg depends on:
ii  kdelibs4                    4:3.1.2-2.1  KDE core libraries
ii  libart-2.0-2                2.3.13-1     Library of functions for 2D graphi
ii  libc6                       2.3.1-17     GNU C Library: Shared libraries an
ii  libfam0c102                 2.6.10-1     client library to control the FAM 
ii  libgcc1                     1:3.3.1-0rc1 GCC support library
ii  libkdegames1                4:3.1.2-2    KDE games library and common files
ii  libpng12-0                  1.2.5.0-4    PNG library - runtime
ii  libqt3c102-mt               3:3.1.1-9    Qt GUI Library (Threaded runtime v
ii  libstdc++5                  1:3.3.1-0rc1 The GNU Standard C++ Library v3
ii  libxrender1                 0.8.2-1      X Rendering Extension client libra
ii  xlibs                       4.2.1-9      X Window System client libraries
ii  zlib1g                      1:1.1.4-14   compression library - runtime

-- no debconf information



--- End Message ---
--- Begin Message ---
Version: 4:3.5.6-1

On Wed, Jul 30, 2003 at 01:27:29AM +0200, Roland Illig wrote:
> Package: kmahjongg
> Version: 4:3.1.2-2
> Severity: minor
> Tags: upstream
> 
> Hi,
> 
> I'm currently playing Kmahjongg over a 10 MBit half duplex line. Every
> time I click at a piece it takes some seconds until the screen is
> updated. I think it is because the complete client area of Kmahjongg is
> calculated and then drawn on the screen.
> 
> For me, it would be better if only the area that really changed would be
> updated, as this would save a lot of bandwidth :)
> 
> Suggestion: You could always have a memory bitmap of the current screen
> and then calculate the new screen as another memory bitmap. Then you
> could check which lines are different, and only make these lines
> candidates for repainting. Then, for every line you could calculate the
> interval that actually changed and then paint that interval.
> 
> If that algorithm is too slow for normal viewing (local, with graphics
> accelerator), you could add a configuration option to switch between
> these algorithms.


Bug fixed in KDE 3.5.6

Ana

--- End Message ---

Reply to: