Marcus Sundberg wrote:
>
> Stefan Seefeld <[EMAIL PROTECTED]> writes:
>
> > Speaking about video and animation, may I come back to
> > a suggestion I had a couple of weeks back ?
> >
> > I proposed to separate the 'Visual' structure into a
> > 'Drawable' and a part concerned about event handling.
> > The argument is quite in line with Andreas' request to
> > refactor functionality in decompressing and drawing:
> > Drawing and event handling have *nothing* to do with
> > each other.
>
> Sure they do, how else would you know what happens to the visual?
> Expose events and such.
There are two answers. If you consider an application with
multiple visuals (similar to X with multiple windows) you'd still
listen to one port which reports events. These events would then
tell you what the target visual is (if ever the notion of target
visual exists). That is, the event would refer to the visual, not
the visual to the event (queue). I always thought (and Jon's answer
seems to confirm that) that your visual is indeed more what a Display
is in X, not an equivalent to a Drawable (== output device).
The second answer is related to the way berlin operates: we have
one single visual representing the screen. There are no 'expose events'
since there is nothing outside which could hide and expose parts of
a visual. If I speak of events in this context I exclusively mean
input events. Region management is done in berlin around the scene graph
we maintain.
> Besides I'm not really sure what you mean by separating out the
> event handling from the visual structure. Of the whole ggi_visual_t
> there is one single pointer related to event handling, isn't that
> separated enough for you?
Ok, I admit that the overhead is not big. May be I'm not completely
understanding what a visual is / is supposed to be. As I said, output
and input are conceptually different. Input comes from one source, which
I can watch by means of ggiEventSelect; output goes to any number of
drawables I want to. So on this conceptual level I don't see why they
are combined into one entity.
I can, however, certainly live with an unused pointer in each 'drawable'
I allocate for offscreen drawings. It just doesn't feel right.
> A manager for video memory will be implemented in LibGGI soon,
> Andy and I have just talked about that. This will make it simple
> to implement an extension for offscreen images.
excellent !
Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
