FreeLists / haiku-appserver / [haiku-appserver] Re: BScreen support

[Adi Oanca <adioanca@xxxxxxxxxxxxxx>]

Hi,

Stephan Assmus wrote:
>>I guess that's a simple and flexible way to do it.
> 
> I agree. And I would like to add that I wanted to pull the 
> "HWInterface" instance out of DisplayDriver and remove the display mode 
> and cursor related functions (which it forwards to its HWInterface 
> instance) from the DisplayDriver API. In the end, I would like this API 
> to contain only drawing related functions. The reason is simple: When 
> we support drawing into BBitmaps, we can attach a DisplayDriver 
> instance to a ServerBitmap, but all the cursor and screen mode related 
> functions don't have anything to do with it.

        Agreed. Seems like a natural thing. :-)

> Note however, that the 
> existing DisplayDriver code would not have to change (so the drawing 
> functions would still try to hide a software cursor and such, only that 
> the BitmapHWInterface would have empty implementations for that).

        Nice.

> P.S. About performance concerns: Some of the code that the RootLayer 
> thread executes scales pretty bad, for example the algorithm used for 
> rebuilding layer clipping. Before we worry about saving performance by 
> trying to make locking unnecessary, we need to worry about the 
> algorithm first.

        Nah, the algoritm is just fine. I did some tests a while ago an it
seemed to perform pretty well. At least those ms were very few.
        I'm curios, what makes you say that?
        If it is a problem, it may be because in some cases a
biger-than-required region is invalidated, or a more general target
(WinBorder) is targeted, or because of a bug somewhere...

        In the little free time that I'm having, I'm writing a more clear,
simplified version of the clipping code(/region rebuilding), but the algorithm
is the same. I will write you about this code and share it with you and in
the end I'm sure we'll come up with the best solution.

> Otherwise it is a ridiculous discussion. And before we 
> even worry about performance at all, we need a correct implementation. 
> Anything else is premature optimization.

        Do not agree. At least in the context of our discussion. A good design
should be enforced from the start. If we did not had a SMP friendly design
final optimizations could not get as much performance of a SMP machine if we
did not take that into account.


bye,
Adi.