On Tue, Jan 21, 2003 at 09:11:17AM +0100, Philippe Ney wrote:
> > Bitmaps aren't widgets, so calling pgGetWidget on them won't work.
> >
> > Maybe it would help to know more about what you're trying to do?
> > If you need direct access to the framebuffer for video playback or
> > a game, that would be a nice feature to put in a (still nonexistant)
> > media_c library.
>
> Ya sure!
> I currently just do some tests to have an idea about what is possible.
>
> > What confuses me about this is why you need to get the
> > position of a bitmap inside a button. Is this for a thumbnail of some
> > sort?
>
> To place a bitmap on the screen, I need to put it in a label and the label
> widget is derived from the button (-> the 'button_get' call...)
>
> I want to use a bitmap to use the same screen space to display an image and
> to do video.
ah.
For this test, I'd recommend using a canvas widget with the bitmap inside
(take a look at the source to the picogui driver in SDL if you want an example)
This way you can be sure that the bitmap is the only thing in the widget.
For the 'real' implementation, the best way I can think of so far would be
a new widget that would cooperate with the video driver to grant the application
permission to a section of the framebuffer.
The main reason this hasn't been done already is that there are a lot of issues
you have to worry about when writing directly to the framebuffer from an app:
- How can the video driver get an application access to the framebuffer
in a relatively portable way?
- When the widget is resized, you need to synchronize the app's drawing with
PicoGUI's drawing
- If sprites are overlapping the area, what happens?
The resizing problem could probably be solved by forcing the app to lock and
unlock the area before drawing to it, using System V semaphores or equivalent.
The sprite problem would be harder- you could use the same locking system to
hide and show the sprite, but that would flicker. You could just hide sprites
entirely in any of these direct rendering areas. You could set up a way for
pgserver to send the app info about the sprites, so it could draw them itself.
Lots of options.
The solutions to these problems will probably evolve over time, another good
reason for them to be abstracted in a media_c library. That does tie fast graphics
support in picogui to one language, but in this case I don't think it's a problem.
In media player applications you pretty much always have something C-compatible
doing the low-level rendering. If this changes in the future, the protocol
would still be valid, only a new media library would need to be written.
>
> > If it turns out that this is the best way to go about whatever it is
> > you're doing, the information you want is in the 'btnposition' structure
> > in the button widget. You'd want to use the absolute x,y position plus
> > the vector (x+bx, y+by) from btnposition.
>
> Ok. I'll try this now.
> Thanks Micah,
> -philippe
--
Only you can prevent creeping featurism!
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel
