|
[haiku-appserver]
||
[Date Prev]
[10-2005 Date Index]
[Date Next]
||
[Thread Prev]
[10-2005 Thread Index]
[Thread Next]
[haiku-appserver] Re: (new clipping code) breakthrough and t
- From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Wed, 19 Oct 2005 16:35:18 +0300
Hi Axel,
Axel Dörfler wrote:
Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote:
We are using it, but it's OK until we connect it to the server, after
that
it's not safe anymore, it's data may be old because it will not be
updated correctly.
How come it used to work before? (or didn't it, and we just didn't
notice?)
The bug was here from the beginning. As you said, we just didn't
notice.
BView::Bounds() is often used, and so it would really be nice if we
could use a cached value.
Yup, that's why I wrote you guys.
Couldn't we just introduce another message that the server sends in
case of an update?
Well, that's what I thought first, but we'll be back to the
discussion we had a few days ago - one message for each view or a single
one which contains data for all views which had their frame changed. And
that's what I proposed in the first mail today.
One that is only forwarded to the frame events if that flag is set?
We have to update every view that had its frame modified on the
server side, not only those views which have B_FRAME_EVENTS flag.
Or just a broadcast a message to all views of that window to invalidate
their cached data?
Yes, this is quite a good idea.
Now we have to decide which of the 2 options to implement. Both
seem to be quite good.
The first one uses only one message but has to search a view for
every "_token".
The second uses more messages but does not have to search the
view tree. Also it is simpler.
I for one, vote with the first approach, because we already have
80% of code in place(the code Stephan wrote for B_VIEW_RESIZED/MOVED).
bye,
Adi.
|