[haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sun, 19 Jun 2005 14:28:24 +0300


Axel Dörfler wrote:
BTW why does PushState() do a initCachedState()? AFAICT this is wrong, it must not reset the state, only the changed bits, right?

Yes, it's wrong. When I wrote that method I was under impression that the whole state must be reseted to defaults. After a talk with Stephan and this mail from you I went testing. Also I read again the documentation and it appears only the scale, local origin and clipping region are reseted - at least that's what the BeBook says and my little test showed.
I know Stephan has tested this more deeply. Stephan?

As far as safety concerns, I agree, we have to make this safer. It shouldn't be possible to pop the state pushed before Draw() was called.

That state must always be the initial state, anyway, doesn't it?

Um... R5 behaves different than we thought.
For example, if I do a PushState() and change the high color every time when I press a mouse button, and in Draw() I fill the bounds with the high color, when moving the window outside the screen and back again, the window is cleared in the last color set by SetHighColor() in MouseDown().
This means it does not reset to initial state, but use the one active before Draw() was called.
I don't know if that's good or bad... we have to decide.

Another thing that R5, IMO, does badly is that before calling Draw() on an update event it pushes the current state and after Draw() is finished it calls PopState(), only once!
So, if I do a lot(try 2) of push states in Draw(), when we get out of it, the state remaining active is one of those pushed in Draw(). Is that correct?
Shouldn't we go back to the state which was active before Draw() was called?
Shouldn't we reset to the initial state, push a state and then enter Draw()?

Axel Dörfler wrote:
>>        Nah, leave it like this. As I said in the other email, I just
>>wanted to
>>point out where the mistake was. I'm fine with this method also.
> I couldn't help but have a look at it and shuddered. Do you intend to
> fix this one day or do you think just searching for the token this way
> would be okay??
> Because it's not okay, only as a temporary solution we can live with it
> right now.

        Don't know, maybe. But right now I don't plan to. It's good how it is 

bye, Adi.

Other related posts: