On 3/28/07, Philipp Lohmann - Sun Germany <[EMAIL PROTECTED]> wrote:
You're all talking about stopping SalTimer because of paint handling.
This is not correct at all, SalTimer is the central mwthod for Timer
base stuff in the whole of OOo - the paint timer is just one Timer of
many. So simply not implementing SalTimer will not gain you much, the
office will not work very well since so much of it is timer based. If
you want to disable the timer based paint handling you'll have to look
in vcl/source/window/window.cxx where (sadly in the independent part)
where you can disable the asynchronous paint handling.
Ah, I guessed saltimer was not only about paint events :) So I'm only
speaking about the painting part of SalTimer.
If we disable asynchronous handling, does that break the refresh? Or
are we still getting everything drawn (although in smaller pieces)?
However this is only the tip of the iceberg. Applications can and will
paint whenever they want to - usually as a reaction to other events like
focus, button clicks, mouse movements, whatever. Throughout the office
we will have to change these places to call Window::Invalidate instead
of painting directly; and of course Invalidate will need to be forwarded
to the system itself which it currently is not - I assume that there is
a method on MacOSX to trigger a paint event through the system.
I think the closest equivalent in mac is a sort of "invalidate region"
-function which then marks that area dirty (MacOSX itself decides
_when_ that dirty area is repainted)
So switching to use ::Invalidate (region?) and then implementing a
aqua native version of that would be propably the good way to go. Of
course this will need some long term work.
Now, what does that "painting directly" really mean? If that direct
painting is already handled by current native VCL implementations,
then I think we can also do that for Mac OS X so that we have a
mixture of direct paints and ::Invalidates... and we fix the direct
paints to invalidates in the long run.
As a start of course one can make the paint handling in window.cxx
synchronous.
Yes, we should definately try this.
Don't get me wrong, I think that nowadays it would be a great advantage
if paint were only done in the paint callback, not only on MacOSX, but
on Windows as well (on X11 platforms this problem is irrelevant since
all real painting is done in the Xserver anyway which is another
process). For example synchronous painting would have saved AW tons of
pain when implementing his overlay buffer stuff. It's only that this
cannot be achieved at a central point. For a while we'll have to live
with this behavior and remove the "out of order" paints step by step.
The painting in window.cxx is certainly the best first step to do this.
So can these direct paint -> invalidate changes be done for all
platforms then? This would make it lot easier to detect bugs. It would
also probably be good to do those on a separate cws, not on
aquavcl01...
Doing it for all platforms could make it easier to have other
developers join to the cleanup work :)
Mox
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
