[interfacekit] Re: :) Again - BBitmap

On Tue, 29 Oct 2002 14:25:37 +0200 "Adi Oanca" <adioanca@xxxxxxxxxxxxx>
 wrote:
>     Because I have reached the section where I have to implement 
> Drawing
> Functions, and because, when the IK Team debated some "GUI problems" 
> I was
> learning and sustaing my last exams of CS, I must bring this subject 
> again
> to the list. Sorry....

No need to be sorry. :-)
I hope everything went well.

> OK, here is what I have to say.
> 
> I've read the hole thread regarding our GUI problems. I must say, 
> that I did
> not see any decision being made. There was a proposal from DW, that 
> part of
> you guys have agreed.
>     So, with this thread I am hopping to finish this subject in order 
> to
> finish the BView and BWindow implementations. Please us give the best 
> ideas
> you have.
> 
>     DW, said we should use BBitmapUtils, a class that makes the 
> drawings on
> the client side.
>     Although this solves BSlider problem, it brings us another, I 
> (Ingo and
> Marc) might say BIG problem - The lack of HARWARE ACCELERATION!!! I 
> don't
> know why you guys have let this subject go!?!?

On my part mostly, because I know too little about graphic cards. E.g. 
I have no idea whether graphic cards can draw into main memory. I tend 
to think not, but that means nothing (though I believe, graphic cards 
support overlay from RAM (not only from graphic card memory as the 
BBitmap flags suggest)). That was why Axel proposed that someone in the 
know should be contacted (e.g. Rudolf Cornelissen).

On the other hand, the implementation idea we discussed -- implementing 
the BView drawing methods so that they allow for both application side 
and app server side drawing -- is flexible enough, I think. On 
initialization of the bitmap it can be decided whether it shall be 
drawn application or server side, and the BView drawing methods would 
simply draw (or let draw) the chosen way. Off-screen bitmaps would 
certainly be good candidates for being drawn-to server side, while 
bitmaps for which accelerated drawing couldn't be done anyway, can as 
well be drawn-to application side, avoiding the communication (and 
thread) overhead. BSliders in particular could use a private API to 
tell their bitmap to do the drawing application side (in case graphic 
cards might indeed support drawing in RAM, otherwise this wouldn't even 
be necessary), which solves the discussed problem.

> This is of a big importance,
> as you surely know 2 of the 3 most known operating system present 
> today, OS
> X and Windows Longhorn use, not 2D as we want, but 3D 
> acceleration!!!!!
>     As graphic cards today have A LOT of memory and 2D/3D 
> functionality
> embedded, WE MUST use the features they have! Bitmaps are from the 
> start,
> one thing that graphic cards come with full support .
>     Because we think into the feature, we must be competitive, my 
> opinion is
> that, although we do not have support for 3D acceleration, we MUST 
> lay down
> an infrastructure to support that, and for now that we have 2D 
> acceleration
> we should use it! I do not like tweaking, for poor quality coding you 
> get
> poor results.
> 
>     HW acceleration involves that all drawing be done on server, and 
> our
> biggest problem is to get those drawing instructions on server. HERE 
> I am
> asking you to come up with the best ideas you have!
> 
> ========
>     I do have one. :-) It has already been discarded by Marc, but... 
> it
> might be a starting point.
> 
>     Why not have ONE off-screen window per BApplication, and all
> BBitmaps be (special)children of it? a thread(window) that will be 
> spawned
> when the first BBitmap object is
> created.
>     A second thought: When, there is no BBitmap object active in
> BApplication space, this thread is destroyed.
> 
>     There is a downfall to this approach as Marc says:
> <I don't know how good one thread would work, as multiple "windows/
> threads"
> may want to draw their offscreen bitmaps at the same time, and you 
> would
> lose your multi-threading like this.>
> 
>     I do agree here. But this will happen rarely, I think. In most 
> cases it
> will work.
> ========
> 
>     From this idea, another came to me.
>     We still have a specialized (a main)thread to make the drawing of 
> a
> BBitmap. If another BBitmap wants to draw at the same time, we could 
> make it
> wait... a quarter of a second(or less :-) and if the main thread 
> still has
> drawing to do, we'll spawn another thread for the second BBitmap to 
> talk to.
>     After it finishes its drawing it monitors the main thread to see 
> if it
> finished drawing
>         - if it did, it acquires the main thread lock, sends to the 
> second
> BBitmap the port of the main thread and then quits.
>         - if it didn't - THIS CHOICE  I  LEAVE TO YOU - either it 
> quits, and
> the next drawing instruction from the second BBitmap takes us from 
> the
> beginning OR we create a pool in witch we wait for the main thread's 
> lock
> and periodically check for a (drawing)message at our port. I vote for 
> the
> second approach :-).
> =======
> 
> What do you say?

If I understand it correctly, the issue your proposal wants to address 
is, that a huge number of app server threads is spawned, when many 
BBitmaps that accept views are created (the BSlider problem). The 
question is, whether this problem still occurs, when we do all drawing 
that can't be hardware accelerated anyway on application side. That is 
basically a question of graphic card capabilities, in particular 
whether drawing in RAM is possible. If it is and we also want to use 
that feature for BSlider, then we should indeed think about a way to 
minimize the number of threads. (... and also about how the equip the 
app server with more resources -- I want to be able to have more than 
100 open windows without windows/apps beginning to freeze.)

Your first approach -- having one app server thread per app doing all 
the bitmap drawing -- seems to be straight forward, but indeed, we 
would lose multithreading advantages. The extension -- spawning another 
thread when needed -- doesn't sound that good to me. This would add 
quite some latency. If the second thread is kept afterwards, that would 
happen only the first time, though. Supposing, that the same situation 
can happen again (just with two busy threads), would a third thread be 
spawned? A fourth,...?

An alternative approach would be to use the current (R5) strategy, but 
have a cut-off number of threads. That is one thread is created per 
bitmap until that number is reached, and further bitmaps are assigned 
to the already existing threads. So, if the cut-off number is 10 and we 
have 15 bitmaps accepting views, then we had 10 threads, five of which 
would service two bitmaps. At 30 bitmaps each thread would deal with 
three bitmaps. And so on...

Anyway, before trying to work around a problem that perhaps doesn't 
even exist (or more precisely can be dealt with simpler), we should ask 
someone, who can tell us more about graphic card capabilities.

CU, Ingo

Other related posts: