Bug 118711

Summary:	(PATCH) highlighting kmahjongg tiles causes audio skips
Product:	[Applications] kmahjongg	Reporter:	Andreas Leuner <almighty>
Component:	general	Assignee:	Albert Astals Cid <aacid>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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) ); 
+	} 
     }
 }