[haiku-appserver] Re: invalidation again

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 21 Apr 2005 10:54:37 +0200 CEST


Adi wrote:

> > I must say I don't like the design with the "current layer". I 
> > think 
> > that the layers and the data they carry is munched together with 
> > the 
> > managing of multiple layers. This is the confusing part. So inside 
> > an 
> > instance of layer, there is code concerning that layer (instance), 
> > and 
> > then there seems to be code as if Layer was a static class. You set 
> > some member variable of one layer instance, to manage another 
> > layer. So 
> > it is completely confusing, which layer we're actually updating or 
> > changing. You don't see this from the code, it just "happens" to 
> > work 
> > if the client code knows what it is doing. This is not necessarily 
> > good 
> > code, the correct usage should be enforced by the design, this 
> > would 
> > make it all much more usable. And I think most of the bugs come 
> > from 
> > client code not actually doing all the necessary things in order 
> > for 
> > the mess in Layer to "magically" work correctly.
>       Believe me I can understand your frustration. I know that piece of 
> code 
> is not easy to understand. I wrote that code with only one objective 
> in 
> mind: speed. If that I sacrificed the beautifulness of C++: the OOP 
> design.
>       I have tried, and succeeded to shoot more than one rabbit at a 
> time. In 
> the same loop I managed to calculate the visible regions, the  
> regions 
> which should be redrawn, to resize and move all child layers, to 
> create 
> a list of regions who should be blit on screen _no matter_ the resize 
> directions of a layer. (Note that for center and right aligned view, 
> R5 
> invalidates the whole view's visible area. I only invalidate what 
> really 
> needs to be redrawn).

I want to add my two cents here:

->Speed can be a good reason to not implement total safety as Stephan 
would like to see it. 
Ever read the openGL reference manuals??? It's exactly the same here. 
Of course: a good description of what you should and should not do ( as 
a user) is something people can't do without...

Of course I do agree that _only_ if a _real_ speed diff can be gained 
this should be acceptable...


Other related posts: