On 3/27/07, Philipp Lohmann - Sun Germany <[EMAIL PROTECTED]> wrote:
tino rachui wrote:
> Sébastien PLISSON wrote:
>> Working on events, I ve started using Thread viewer to watch if
>> everything was going well,
>> and Ican see the thread where SalTimer resides.
>>
>> I wonder what is the role of SalTimer events and thread hits ?
>>
>> The runapplicationeventloop from carbon/apple api is sufficient to
>> manage events sot is saltimer still useful ?
> VCL draws timer driven! This contradicts the philosophy of almost all
> modern GUI based operating systems. But is a history relict of VCL.
> Don't ask me what people drove to come up with such a weird design
> decision.
Simple. Paint events get concatenated for a while to one larger paint
event since at the time (and possibly still) applciations tended to be
faster drawing a large rectangle once than many small rectangles five
times (or whatever). This was quite noticeable on your average Pentium
III 500.
So this VCL-behaviour can be somehow massaged to work with WinXP and
Unix/X11 by explicitly forcing painting whenever that saltimer
wants... (?)
...but on Mac OS X/Quartz you are not really supposed to do that kind
of direct activity: Quartz has its own timing/drawing mechanism itself
(30 fps?). And trying to explicitly force painting only results to
dreadfully slow apps :/
Having two different timing systems compete with each other... ouch,
I wonder if it would make worth the effort to just find ways to rip
out the saltimer for Mac OS X, or at least show some crowbar massage
to it so that it doesn't get in the way.
Mox
