[interfacekit] Re: :) Again - BBitmap

>  wrote:
> >     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.
>
> Good to know.

    Marc also knows something about DirectX and OpenGL. :-)

> >     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!!!!!!!!!!!!!!!!
>
> Sure, noone argues against drawing into bitmap for which hardware
> acceleration would be available on app server side (off-screen bitmaps
> for now). But I don't see the point in drawing every bitmap there. If
> current graphic cards can't draw into main memory, then why should the
> app server do the drawing, when we can save a thread, communication
> overhead, and latency (less context switching) by drawing application
> side?

    Latency? Please explain. All I can say, is that, we can lower to 0 the
time we wait for the (main thread)/(one thread) in my/your solution.

    "Why should the app_server do the drawing"? I'll give you one (I might
say DAMN) good reason. SPEED! I am ready to make a bet: we make a test with
the drawing being made server-side vs. drawing being made app-side, for
about a minimum of... 50 drawing instructions. I have no doubt that the
server will get the crown - with all the communication and a new thread
being spawned! Then... imagine for 200, 400 d. i.... a BIG difference will
appear. THAT IS WHY accelerated hardware exists!!! As an example: try
running Quake I in software rendering mode vs. running it on the latest
generations graphic cards - AND note that the T&L engine won't be used...
only "raw" rendering... and ALSO note in software rendering d. i.s are
optimized for speed - that's why it looks ugly.

> > > 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?
>
> For always only doing the work with the minimally possible overhead.

    This is not flexibility. :-) This is efficiency. :-)
    :-) Flexible would be a fast drawing engine that can do accelerated
drawing onto screen as well as into bitmaps.

> > > > 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!
> [...]
> > COME ON PEOPLE! MORE IDEAS! THIS IS ONE BIG PROBLEM THAT *MUST* BE
> > SOLVED!
>
> Your enthusiasm is certainly appreciated, but I fail to see, what you
> want more.

    Now that I finished the faculty, I will get employed. I'll go into
Bucharest and try to do (at Ubisoft) what I want to do in my
life(programming side:-): create games. You must see the similarity between
this and a game:-). Because I want the best for this project I insist for
you to agree with me! :-)

    Because we have 2 methods, it doesn't mean that a better one doesn't
exist!

> We have
>
> 1) ... an idea for getting rid of all bitmap drawing app server thread
> where they are not needed (in cases where no hardware acceleration
> would be available).

    7 years have passed since the fist 3D card has appeared! I REALLY don't
think that there is someone who doesn't have one! And if it is... I surely
don't want to support his needs! This is a Multimedia OS, we have some
requirements, don't we?

> Which as a nice side effect also has other
> advantages, like no communication overhead and a lower latency in the
> respective cases.

    I repeat: Communication it's not an issue! And about the latency: Don't
worry, it's bigger when you draw onto screen (that is, if you don't use a
double buffer :-)!

> One could even go so far to argue that it's the
> responsibility of the developer then -- it's their own fault, when they
> create 100 off-screen bitmaps and experience problems due to that.

    Well... I stand between... either way, we must provide the best cost
solution we can come up with.

> 3) ... the need for a solution of a real problem, which would be to
> raise the resource limits for the app server.

    Yes, I completely agree here!


Adi.

Other related posts: