[Scummvm-devel] [Scummvm-cvs-logs] SF.net SVN: scummvm:[38881] scummvm/trunk/engines/sci/gfx

[Max Horn]

Am 25.02.2009 um 15:17 schrieb Walter van Niftrik:

> Hi Max,
>
> fingolfin at users.sourceforge.net wrote:
>> Modified: scummvm/trunk/engines/sci/gfx/operations.cpp
>> ===================================================================
>> --- scummvm/trunk/engines/sci/gfx/operations.cpp	2009-02-25  
>> 18:23:28 UTC (rev 38880)
>> +++ scummvm/trunk/engines/sci/gfx/operations.cpp	2009-02-25  
>> 18:59:00 UTC (rev 38881)
>> @@ -1626,6 +1626,9 @@
>> 		GFXERROR("Failed to remove pointer before processing event!\n");
>> 	}
>> +	// Update the screen here, since it's called very often
>> +	g_system->updateScreen();
>> +
>> 	// Get all queued events from graphics driver
>> 	do {
>> 		event = state->driver->get_event(state->driver);
>>
>
> We now have updateScreen() in both gfxop_get_event and gfxop_sleep.  
> As the latter also calls gfxop_get_event this seems to be overkill.

Yes, it is overkill (though it should cost virtually no performance to  
kill it that often).

> Also, there's another updateScreen in gfx_driver.cpp, so if we do  
> want an updateScreen call in gfxop_get_event its only purpose would  
> be to redraw the mouse cursor. So perhaps the comment should be  
> rephrased.
>
> Why did you make this change, was mouse performance still inadequate  
> after wjp's mouse patch?

Well: Note that this updateScreen call was there before, only inside  
get_event (Granted, get_event() only updateScreen upon mouse moved  
events or when the mouse cursor was changede). My intention is to get  
rid of this call eventually. But without causing regressions... For  
that it seemed logical to start by pushing it upward in the call  
chain. That will hopefully make it easier to eliminate it eventually.

So, yeah, this can likely be removed, but I didn't want to be blamed  
for regressions.  :)

While I am it: I would suggest somebody merges gfxop_get_event and  
scummvm_get_event. A merged function should be quite a bit shorter  
than the sum, if you know what I mean; some redundancies could be  
removed. (The result of the merger could still be split across two  
functions, though, to avoid having one gigantic function; I just think  
that the current separation is not the best).


Bye,
Max