[interfacekit] Re: :) Again - BBitmap

> No need to be sorry. :-)
> I hope everything went well.
    Very well, thanks!

    To clear some things from the beginning.

    I know something about graphic cards and how they work. 3 years ago, I
intensively studied for 4 months DirectX API (the graphics part - 2D&3D),
and did some programming with it. Since then, I've constantly monitored the
new features of the new graphic cards as well as those of the APIs.
    I can tell you one thing for sure: graphic cards do not render into main
memory! Not even those that use some of the main memory(those that are
integrated into the mainboard chipset)!
    They can communicate with the main memory very fast through the AGP
port, but that is mainly used by APIs (DirectX | OpenGL) to transfer
data(bitmaps & vertex data) from the main to video card memory when it is
needed.
<my opinion>
    Unfortunately, for the time being, this is one thing that our app_server
must to - take the place of a game API - in order to achieve FORMIDABLE
results. I say - for the time being, because, I bet that for the R3, R4 the
latest, our app_server will use OpenGL for rendering/clipping, and who
knows, maybe T&L (Transform(ation)&Lighting) for some amazingly effects. :-)
</my opinion>

    I will talk and talk ... and talk about this until you all agree to
render into bitmaps on the server-side, because sooner or later, I'm sure
that we will do that because of the hardware acceleration. WE MUST do that,
I've already told you, OS X uses OpenGL to render its UI, Windows will use
DirectX to do that. WE MUST follow them, WE MUST say in sync with the
times!!!!!!!!!!!!!!!!

>(though I believe, graphic cards
> support overlay from RAM (not only from graphic card memory as the
> BBitmap flags suggest)).
    No, they do not! Overlays are bitmaps that stay in video card memory. At
present time, AFAIK, overlays cannot anywhere else but in video memory,
because of they are needed for fast clipping on every frame that it is drawn
onto screen.

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

    Excuse me for how this sounds,but I can't find another way :-). Flexible
for what?

> well be drawn-to application side, avoiding the communication (and
> thread) overhead.

    The thread overhead problem we must resolve. Communication is not a
problem!

> BSliders in particular could use a private API

    I do not agree! We must provide a standard, that should be used by
everybody! BSliders have no reason to use a particular API! Developers may
want to use off-screen  bitmaps for their purposes also. what should they
do, contact us to provide them an API? No! one *damn good* API for everyone.

> > I am
> > asking you to come up with the best ideas you have!

    OK, For now there are 2 ideas to solve out thread problem: MOOOOORE,
PLS!

1)
=======
ver: 1.1

    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...
<UPDATE>
> a quarter of a second(or less :-)
    no, it's too much, 1/50 of a second I think is OK
</UPDATE>
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 we create a pool in witch we wait for the main
thread's lock
and periodically check for a (drawing)message at our port.
<UPDATE>
    if, in... half of a second there hasn't arrived a package at our port,
we'll quit and go from the beginning
</UPDATE>
========

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


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

    Yep! I suppose that operation won't last to much. With ver 1.1 that is a
little bit more efficient :-).

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

    Yes! That is one good approach. Bravo!


COME ON PEOPLE! MORE IDEAS! THIS IS ONE BIG PROBLEM THAT *MUST* BE SOLVED!


Adi.

Other related posts: