[interfacekit] :) Again - BBitmap

Hello to you all!

    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....

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!?!? 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?

Other related posts: