Re: multi head porting
- From: Owen Taylor <otaylor redhat com>
- To: Hans Breuer <hans breuer org>
- Cc: gtk-devel-list gnome org
- Subject: Re: multi head porting
- Date: Fri, 10 May 2002 11:01:21 -0400 (EDT)
Hans Breuer <hans breuer org> writes:
> The attached patch allows to compile gtk head on win32
> again (not supporting multiple screens yet).
> It was done with the major goal to minimize the required
> changes on the backend code.
Thanks a lot for looking at this. I've been meaning to try
and get some time to get the other backends straightened up
but haven't had any time.
Did you see:
I'm not sure that minimizing the required changes to the
backend code is really the right goal. I think, instead,
the right goal is minimizing the total amount of backend
If we take your approach of:
gdk_display_beep (GdkDisplay * display)
g_return_if_fail (GDK_IS_DISPLAY (display));
Then we need to implement:
gdk_display_beep: in gdk/x11/ and gdk/
gdk_beep: in gdk/x11/ and gdk/win32
While if we turn it around and do:
gdk_display_beep (gdk_get_default_display ());
Then we need to implement:
gdk_beep: in gdk/
gdk_display_beep: in gdk/x11 and gdk/win32
Which is both less implementation and a more straightforward
implementation. The Win32 gdk_display_beep() implementation should be
as simple for now as changing
gdk_display_beep (GdkDisplay *display)
For code that really does need to be duplicated between all
single-head ports, it certainly makes sense to figure out a way
to put that in gdk/, though it might be easier to do one port first
(say Win32) and then try to figure out from there what makes
sense as common code.
> With this goal in mind there
> are some places where it could get huge improvements if the
> multi-head api isn't inscribed in stone yet :
> Only the multi-head version needs to store a screen with
> every colormap. Single Head version would return the
> default screen. [The GdkScreen* field from the GdkColormap
> struct could be removed and the multi-head version would
> maintain it's own hashlist to remember the Colormap/Screen
> Same logic as for gdk_colormap_get_screen(), removing
> GdkScreen* from _GdkVisual struct, whiches content needs to be
> maintained by the backend.
We could move the GdkScreen structure in to the X11 private
part ... I don't really see much of a difference though.
> gdk_event_* ()
> Removing the display parameter from the gdk_event_* () function
> again and determining it from the window given in _GdkEventAny
> would allow for multple event queues but did not enforce
> them. [They appear unnecessary on win32 even if it would support
> multi-head. And they are obviously unnecessary for any gdk port
> which is bound to single-head through real backend 'limitations'
> (linux-fb, directfb ?).]
The hierarchy we have here is:
* GdkDisplay ... a set of monitors on one system with an attached
keyboard and mouse.
* GdkScreen - a separate virtual area of one or more monitors,
with it's own set of colormaps and visuals.
* gdk_screen_get_n_monitors() [etc]... find out how many monitors
a screen is made
To my knowledge, win32 can "only" do multiple monitors, so I
don't think there is ever going to be multiple screens or
multiple displays for win32.
But I do think that it makes sense that if you have a separate
display ... a separate keyboard and mouse ... then you have a
separate event queue.
In the case of a port supporting only a single GdkDisplay, they
can just ignore the GdkDisplay * parameters to
gdk_display_put_event() and so forth, and use an event queue.
> If we could agree on single-head being the common case (for which
> to optimize) and multi-head being advanced where some extra
> code doesn't matter that much, further improvements to the
> backend independent code are possible, e.g. by allowing
> display and screen to be NULL in the api and maybe totally
> eliminate the need to have GdkScreenSingle and
> GdkDisplaySingle classes ...
I'm not sure what you mean by 'optimize' here.
- Optimize work for backend authors. As I said above, I think
the most important thing is to optimize on-going maintainence,
rather than to optimize the amount of work that we have to
do right now.
- Optimize efficiency? I don't see any significant efficiency
gains that are possible by prioritizing single head.
- Optimize for app authors? None of the non-multihead API has
been removed, so it's possible to write non-multihead-aware
apps and widget just as before.
I've tried the allow NULL to mean the default before in various
places and never been very happy with the result ... it
gives you an odd looking API and obscures what is going
on for the user. Plus, it doesn't work in languages where
methods are really methods.
Single case is a special case of multihead, if we try to organize the
code the other way around, it will be more complicated and
messier ... a similar problem to having GtkCTree derive from
> What do you think ?
> And if you think all the above doenn't make much sense: Is
> the patch in its current form ok to commit ?
I'd really like to see something more like what I outlined
in my mail... move the non-multihead variants into the common
code and only duplicate the multihead variants.
(With non-multihead backends ignoring the screen/display
] [Thread Prev