Bug 118711 - (PATCH) highlighting kmahjongg tiles causes audio skips
Summary: (PATCH) highlighting kmahjongg tiles causes audio skips
Status: RESOLVED FIXED
Alias: None
Product: kmahjongg
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Albert Astals Cid
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-20 12:57 UTC by Andreas Leuner
Modified: 2005-12-20 20:58 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Leuner 2005-12-20 12:57:45 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources

in kmahjongg when I highlight (or unhighlight) a tile there seems to be a high system load for a short moment. During that I observe (noatun) audio skips. That really means for every click.

In addition to this the mouse pointer hangs for that time. That's not nice. It interrupts my "work flow".

This behaviour might be related to that described in Bug #62109.

I have created the following patch that remedies this problem by replacing the 'repaint' call inside BoardWidget::hilightTile with calls to 'update':

Index: boardwidget.cpp
===================================================================
--- boardwidget.cpp	(Revision 485951)
+++ boardwidget.cpp	(Arbeitskopie)
@@ -1537,7 +1537,14 @@
 	}
 	if (doRepaint) {
 		updateBackBuffer=true;
-		repaint(false);
+		if (testWFlags(WNoAutoErase))
+		    update();
+		else
+		{
+		    setWFlags(getWFlags() | WNoAutoErase );
+		    update();
+		    setWFlags(getWFlags() & (~WNoAutoErase) );
+		}
 	}
 }
 
With that patch the problem I described seems to be gone almost completely. There are still tiny mouse pointer hangs that are hardly noticeable. Confining the 'update' to the region of the  changing tile might take care of that. But lazy me I didn't find an easy way to figure out a conversion from board position to widget position. Even so the result is quite acceptable.

According to Qt documentation, 'repaint' causes an immediate redraw of the target area. Other than that 'QWidget::update'
    "schedules a paint event for processing when Qt returns
    to the main event loop",
and thus seems to hurt Qt's work flow less.

While playing I cannot notice a difference between "immediately redrawing" and "scheduling a paint event".

Bye,
Andreas Leuner
Comment 1 Albert Astals Cid 2005-12-20 20:58:21 UTC
SVN commit 490094 by aacid:

Change some repaints to update()
Does not make the behaviour different but seems a bit less CPU-intensive
Thanks for the patch
BUGS: 118711


 M  +32 -4     boardwidget.cpp  


--- branches/KDE/3.5/kdegames/kmahjongg/boardwidget.cpp #490093:490094
@@ -1537,7 +1537,14 @@
 	}
 	if (doRepaint) {
 		updateBackBuffer=true;
-		repaint(false);
+		if (testWFlags(WNoAutoErase)) 
+			update(); 
+		else 
+		{ 
+			setWFlags(getWFlags() | WNoAutoErase ); 
+			update(); 
+			setWFlags(getWFlags() & (~WNoAutoErase) ); 
+		} 
 	}
 }
 
@@ -1547,7 +1554,14 @@
 void BoardWidget::drawBoard(bool )
 {
    updateBackBuffer=true;
-   repaint(false);
+   if (testWFlags(WNoAutoErase)) 
+      update(); 
+   else 
+   { 
+      setWFlags(getWFlags() | WNoAutoErase ); 
+      update(); 
+      setWFlags(getWFlags() & (~WNoAutoErase) ); 
+   } 
    drawTileNumber();
 }
 
@@ -1563,7 +1577,14 @@
 	Game.hilighted[E][Y][X] = 0;
     if (doRepaint) {
 	updateBackBuffer=true;
-       repaint(false);
+	if (testWFlags(WNoAutoErase)) 
+		update(); 
+	else 
+	{ 
+		setWFlags(getWFlags() | WNoAutoErase ); 
+		update(); 
+		setWFlags(getWFlags() & (~WNoAutoErase) ); 
+	} 
     }
 }
 
@@ -1585,7 +1606,14 @@
     Game.putTile( E, Y, X, 0 );
     if (doRepaint) {
         updateBackBuffer=true;
-        repaint(false);
+	if (testWFlags(WNoAutoErase)) 
+		update(); 
+	else 
+	{ 
+		setWFlags(getWFlags() | WNoAutoErase ); 
+		update(); 
+		setWFlags(getWFlags() & (~WNoAutoErase) ); 
+	} 
     }
 }