Re: [AD] al_set_target_bitmap question

["Peter Hull" <peterhull90@xxxxxxxxxx>]

In Java (1.5 and above) BufferedImages have a system-memory
representation and also, if the system decides, a version uploaded to
the graphics card. Also in Cocoa, an NSImage is just a container for
one or more NSImageReps, which are the actual images. OS X decides
which is the best representation to use in a particular circumstance.
It would be good to have a similar system for Allegro, so that the
user does not have to worry about video vs normal bitmaps at all. We
would only need 'memory' and 'uploaded' forms, either of which could
be empty depending on where the image came from (ie. loaded from disk
= memory only, generated by drawing commands = uploaded only). The
image would also get uploaded if you used it as the source for a blit
(or used it a few times) and the memory representation would get
filled in if you tried to lock a portion of an image that only existed
in video memory,

Pete

On Jan 9, 2008 1:17 PM, allefant <allefant@xxxxxxxxxx> wrote:
> On Jan 9, 2008 10:36 AM, Peter Hull <peterhull90@xxxxxxxxxx> wrote:
> > I was imagining there might be problems if you loaded an image from a
> > file and then tried to draw on it. If your main display was OpenGL you
> > would have to upload the bitmap to the graphics card, draw using
> > pbuffers or whatever, then get it back into main memory.
> >
> > Initially I thought that it was going to work like Java or GDI+, where
> > you start with the memory bitmap, then create a display from it, draw,
> > then flush/dispose of the display. Having looked at the current
> > implementation, it seems that loading an image automatically asks the
> > current display to allocate a bitmap, then copies the image to it.
> >
> > I know this was discussed at length before, I suppose I just haven't
> > got my head around it yet.
> >
>
> Well, currently, there are two types of bitmaps: Memory bitmaps and
> display bitmaps, the latter being roughly the same as video bitmaps in
> A4. When you load an image, you get one of the two, by default a
> display bitmap. This means users by default are free from having to
> first load a memory bitmap for everything like in A4, just to then
> create video bitmaps or AllegroGL textures out of it before drawing.
>
> When drawing to bitmaps, whether it is a memory bitmap or not decides
> if the display is involved (like e.g. a driver draws to it using GL
> commands) or we use memory implementations to draw to it. And there
> was no need for something like the GDI "graphics contexts", as we have
> almost no state in Allegro. (We tried to create an alternate API with
> an ALLEGRO_GRAPHICS structure in addition to ALLEGRO_DISPLAY and
> ALLEGRO-BITMAP at one point, should still be on the wiki somewhere,
> but it didn't seem useful.) The only state we have so far as far as I
> can see is:
>
> per-thread: display, blending
> per-display: target
> per-bitmap: clipping
>
> I.e. basically the same as in A4, except for the display and target.
> Likely most A5 apps will have a single display (window) only, so you
> never care about the possibility to choose a different one. But if you
> have multiple windows, it is very easy to do it. And the drawing
> target means you don't specify a bitmap parameter to each drawing
> operation, but the current target is used.
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> --
>
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>