GNOME Bugzilla – Bug 348375
single-DISPLAY full screen support in gnome-mag
Last modified: 2007-01-25 18:30:54 UTC
To support full screen magnification in gnome-mag a some files must be altered and others added, this thread start this process.
Created attachment 69398 [details] [review] This patch alter some file to add support for full screen magnification This patch alter some files to add full screen magnification, using the X server COMPOSITE extension, to gnome-mag. This is quite stable, but this is not enable by default, since it have some nasty bugs to the users. Below is a brief summary of what this patch changes to add full screen magnification using COMPOSITE: * Changes magnifier/damage-client.c, so it can listen the damages that occur to off screen drawables. The logic of the handler whas modified a bit, since the damages can occur to the source drawable and off screen drawables interchangeable (I thought). This way, all damages are received and then the actions are taken in it drawable damaged. * Changes magnifier/magnifier-main.c adding the --ignore-composite=INT option. (this is setted to 1 by default). It's also changes a bit how the sources_bounds are determined, so all the source drawable can be captured. * Changes magnifier/magnifier.c adding the magnifier_reset_overlay_at_idle, this is inspired in magnifier_reset_struts_at_idle, that creates the overlay window (so there's no interference from override_redirect windows in the magnifier window) and makes the mouse clicks go through it using the XShape extension. * Changes magnifier/zoom-region.c adding the choose of the new source drawable if it's available (the COMPOSITE hook was initialized correct).
Created attachment 69399 [details] This is the new file composite-client.c This is the code that tracks modifications to windows.
Created attachment 69400 [details] This is the new file composite-client.h This is the interface used by other files to the implementation in composite-client.c
Hmm, strictly speaking gnome-mag has always had fullscreen support. It requires the 'dummy driver' x server module, in the existing implementation; if dummy driver is available then gnome-mag can do fullscreen magnification (because there are two screens). The new code using COMPOSITE is better since it allows fullscreen magnification without adding a second 'virtual' or 'dummy' screen.
Would it be possible/better to keep the old codepaths for DAMAGE and XFIXES if COMPOSITE is not active? (COMPOSITE is not enabled by default in current x servers... but DAMAGE and XFIXES are).
(In reply to comment #4) > Hmm, strictly speaking gnome-mag has always had fullscreen support. It > requires the 'dummy driver' x server module, in the existing implementation; if > dummy driver is available then gnome-mag can do fullscreen magnification > (because there are two screens). > > The new code using COMPOSITE is better since it allows fullscreen magnification > without adding a second 'virtual' or 'dummy' screen. > Sorry for the confusion.
(In reply to comment #5) > Would it be possible/better to keep the old codepaths for DAMAGE and XFIXES if > COMPOSITE is not active? (COMPOSITE is not enabled by default in current x > servers... but DAMAGE and XFIXES are). > Bill, I think you are refering to the patch in bug #340203 that is modifying the codepaths to DAMAGE and XFIXES. I make some mistake and upload a big wrong patch ;-), sorry for this. I will update it as soon as possible. The changes to the codepaths for DAMAGE and XFIXES that I proposed are in bug #348169
> Bill, I think you are refering to the patch in bug #340203 that is modifying > the codepaths to DAMAGE and XFIXES. I make some mistake and upload a big wrong > patch ;-), sorry for this. I will update it as soon as possible. I put the wrong bug number, it's bug #348203
Created attachment 70573 [details] [review] make the same changes that the first patch does, with minor modifications
Created attachment 70575 [details] This is the new file composite-client.c improved. This work very better than the older one, but still have some gaps.
Created attachment 70576 [details] This is the updated composite-client.h
Created attachment 71416 [details] [review] the same effect as the other patches, but with more modifications.
Created attachment 71417 [details] This is the new file gmag-events.c that join the handlers for composite, damage and xfixes notifications.
Created attachment 71418 [details] This is the interface to gmag-events.c
I'm very satisfied with the last archives. It's working very well with X11R7.1. I also do modifications to it works with X11R7.0 too, but don't expect a good magnification with this xserver version. I really appreciate any feedback about this, because I think that this is in a stage that can be commited.
One issue, when I click and hold on a window's title bar to drag, then the view is not updated smoothly.
(In reply to comment #16) > One issue, when I click and hold on a window's title bar to drag, then the view > is not updated smoothly. > George, what do you say about that "the view is not updated smoothly" is that in the magnified screen the window being moved stay with pieces being showed in different parts? If the answear is yes this was not introduced now, this also happen with the current version of gnome-mag. If the smoothly that you are refering about is that the magnifier has a lost in performance while moving a window, yes it's true and I don't go deep in how to resolve this, since when the render extension be accelerated in hardware probably this will disappear.
It seems that the magnifier stops updating the view until I release the drag operation.
Thanks for the observation George. It´s really true. Probably this is due the priority that x server events have over updating the screen.
I recommend that comment 18 be filed as a separate bug after this code gets committed.
I think that you can already open it, since you can mark this bug as a blocker of the bug presented in comment 18. Only a new comment about the comment 18 is that the magnifier stops updating the view until mouse movements gets slower, and not in the release drag operation.
Carlos, well done. I have to move magnifier_free_cursor_pixels into gmag-events.c because it wasn't finding it delcared (It was in magnifier.c, perhaps not magnfier.h?) I was able to get this running on Ubuntu Edgy 6.10 with a Default install with the X server and composite enabled. Perforamce is pretty good on a Pentium M 2.0 gz 1 gig ram laptop. Thing is running hot but I love the display! Its doing a great job with some of the images. I believe George hit the major issue of dragging windows. I noticed the bug report and I have nothing to add. Remove the old cursor and return "push" to the default (Or has this changed?). It seemed to me that most users expect the cursor to push rather than have it centered all the time. At least as the default behavior... I've been leaving it running on the same portion of the screen and it still seems to be hogging up a lot of resources. I haven't done any real debugging or looking for mem leaks. Overall this a GREAT step in the movement in magnifying. I will work on packing this up for Ubuntu and give it a test to some low vision users.
(In reply to comment #22) > Carlos, > > well done. I have to move magnifier_free_cursor_pixels into gmag-events.c > because it wasn't finding it delcared (It was in magnifier.c, perhaps not > magnfier.h?) I will verify it again here! Thanks for the information. > > [snipped] > > Remove the old cursor and return "push" to the default (Or has this changed?). > It seemed to me that most users expect the cursor to push rather than have it > centered all the time. At least as the default behavior... It's not a gnome-mag politic. Orca/gnopernicus add these logic types. If you start gnome-mag throw orca/gnopernicus you will get the desired behavior. > > I've been leaving it running on the same portion of the screen and it still > seems to be hogging up a lot of resources. I haven't done any real debugging > or looking for mem leaks. I didn't noticed this. I will look with more care to this. Thanks! > > Overall this a GREAT step in the movement in magnifying. I will work on > packing this up for Ubuntu and give it a test to some low vision users. > Test are always welcome. Thanks for this Jason!
These files replace the old ones and improve a little the magnifier behavior when using COMPOSITE. On issue that I percepted after publishing the files above is that it introduces somre regressions making the magnifier only be usable when using COMPOSITE, so with you start it with "#: ./magnifier -vmz 2" or "#: ./magnifier -vmz 2 --ignore-damage" it does not work properly. Now the CPU usage doesn't stay in 100% all the time it's only get high when the mouse moves due the scaling operation, altough the CPU usage is a little higher than before. It also removes the bug #361788 due modifications in the event handling loop. The update is not smooth as I think that good be, but this isn't an issue introduce by this code. I also percept a new bug. If you open this page http://developer.gnome.org/doc/API/2.0/glib/glib-Type-Conversion-Macros.html and scroll-down with the mouse-wheel and the scroll-up also with the mouse-wheel a lot of headers will be appear in the page. This behavior doesn't occur in a normal desktop, but I don't think that this is a gnome-mag bug. Must be investigate in more deep. Have fun with it!
Created attachment 75800 [details] new gmag-events.c I made some modification to orgnize better the #ifdefs used throw the code.
Created attachment 75801 [details] new gmag-events.h
Created attachment 75802 [details] [review] patch with more modifcations
(In reply to comment #22) > <snip> > > I've been leaving it running on the same portion of the screen and it still > seems to be hogging up a lot of resources. I haven't done any real debugging > or looking for mem leaks. In this new patch I don't percept any strange usage of resources.
Comment on attachment 75802 [details] [review] patch with more modifcations Carlos: Please remove the C++-style comments from the code (those are not allowed in gnome code since they are not legal in older versions of ANSI C). Thanks!
Comment on attachment 75802 [details] [review] patch with more modifcations >+AC_CHECK_LIB(Xfixes, XFixesCreateRegion, XFIXES_LIBS=-lXfixes) Does this still work with old versions of the XServer that don't install pkg-config (.pc) files? The use of .pc files with XOrg is fairly recent... >+static MagnifierOptions global_options = { ":0.0", //target_display Please change to /* target_display */ (C++ style comments will break some compilers) ... >+void magnifier_free_cursor_pixels (guchar *pixels, gpointer data); >+void magnifier_set_cursor_from_pixbuf (Magnifier *magnifier, >+ GdkPixbuf *cursor_pixbuf); >+void magnifier_set_cursor_pixmap_by_name (Magnifier *magnifier, >+ const gchar *cursor_name, >+ gboolean source_fallback); >+void magnifier_transform_cursor (Magnifier *magnifier); Should we make these, or some of these, private to the magnifier, i.e. not exported? We could do this with an underscore prefix, _magnifier_free_cursor_pixels() etc. >+ if (magnifier->priv->source_drawable) { >+ zoom_region->priv->source_drawable = >+ magnifier->priv->source_drawable; >+ /* TODO: I think that this ref call can be >+ * avoided. I don't go deep to see why the ref >+ * count of magnifier->priv->source_drawable is >+ * being decremented, so this was a simple hack >+ * that I find to make the things work. >+ */ >+ g_object_ref ( >+ magnifier->priv->source_drawable); I am not comfortable with this patch being committed without having a better understanding of the drawable's lifecycle. The "simple hack" could cause big leaks, which would make the magnifier unusable. Can we make sure we understand the reason for the above ref, and ensure that there is a corresponding unref, before committing? Valgrind might be a good way to do this... Anyhow, I agree, GREAT WORK Carlos! Since this is such a large patch, I do think we need to test building and running it on an older Xserver before committing (at least one without COMPOSITE, i.e. X11R6.8 or X11R6.9 series - maybe it's OK to require DAMAGE and XFIXES now). Bill
Created attachment 76294 [details] minor changes to correct some bugs and adapt to some Bill comments The modifications in gmag-events.c are: * Added Sun Microsystems Inc. copyrights, since this code contains code that pertenced to damage-client.c and magnifier.c * The declaration of fixes_event_base is always made, because in magnifier.c some code depends on this declaration. The code must be reworked a little to remove this issue. * Correct a syntax in the code that query and verify for user ignore of the damage and composite extension.
Created attachment 76296 [details] [review] new compositor patch to adress issues pointe by Bill This new patch adress the issues pointed by Bill and add some modifications due to tests on old systems.
(In reply to comment #30) > (From update of attachment 75802 [details] [review] [edit]) > > >+AC_CHECK_LIB(Xfixes, XFixesCreateRegion, XFIXES_LIBS=-lXfixes) > > Does this still work with old versions of the XServer that don't install > pkg-config (.pc) files? The use of .pc files with XOrg is fairly recent... Yeah, this doesn't need pkg-config (.pc) files for X libraries. > > >+static MagnifierOptions global_options = { ":0.0", //target_display > > Please change to /* target_display */ (C++ style comments will break some > compilers) Sure, changed! I forget to change these ones. I only discover that this type of comments can break some compilers some time ago. > ... > >+void magnifier_free_cursor_pixels (guchar *pixels, gpointer data); > >+void magnifier_set_cursor_from_pixbuf (Magnifier *magnifier, > >+ GdkPixbuf *cursor_pixbuf); > >+void magnifier_set_cursor_pixmap_by_name (Magnifier *magnifier, > >+ const gchar *cursor_name, > >+ gboolean source_fallback); > >+void magnifier_transform_cursor (Magnifier *magnifier); > > Should we make these, or some of these, private to the magnifier, i.e. not > exported? > We could do this with an underscore prefix, _magnifier_free_cursor_pixels() > etc. I remove some uneeded exported function and leave these ones: * magnifier_set_cursor_from_pixbuf () * magnifier_set_cursor_pixmap_by_name () * magnifier_transform_cursor () A major effort in code refactoring is needed to require only one function (the desired behavior IMO) to the magnifier and gmag-events communication. > > >+ if (magnifier->priv->source_drawable) { > >+ zoom_region->priv->source_drawable = > >+ magnifier->priv->source_drawable; > >+ /* TODO: I think that this ref call can be > >+ * avoided. I don't go deep to see why the ref > >+ * count of magnifier->priv->source_drawable is > >+ * being decremented, so this was a simple hack > >+ * that I find to make the things work. > >+ */ > >+ g_object_ref ( > >+ magnifier->priv->source_drawable); > > I am not comfortable with this patch being committed without having a better > understanding of the drawable's lifecycle. The "simple hack" could cause big > leaks, which would make the magnifier unusable. Can we make sure we understand > the reason for the above ref, and ensure that there is a corresponding unref, > before committing? Valgrind might be a good way to do this... I remove the "simple hack" and the code works properly. Probably some detail from old implementations was removed. > > Anyhow, I agree, GREAT WORK Carlos! Since this is such a large patch, I do > think we need to test building and running it on an older Xserver before > committing (at least one without COMPOSITE, i.e. X11R6.8 or X11R6.9 series - > maybe it's OK to require DAMAGE and XFIXES now). I run it on Slackware 10.2. It have a X11R6.8.2 server and the code compile and run properly.
Comment on attachment 76296 [details] [review] new compositor patch to adress issues pointe by Bill Hi Carlos - thanks, this patch looks very good to me. I have asked some of our Beijing team to test the patch against XSun and Xorg 6.9, if they report success then I think we should commit this patch.
I only want to remember that although this works in Xorg 6.9 and 7.0 (the two are the same, the only difference is that one is monolithic and the other modular) the result is not good. The Xorg 7.1 is the one that have the better COMPOSITE extension support and in this version the magnifier result is very good.
Any news about the tests Bill?
Hi Carlos, thank you for the patch. We will test it this week (today). We were kind of short of machine last week because some test work. Sorry for the delay.
Hi Carlos, I tried the patch and Composite extension with Xorg7.2 on Solaris. Before testing, I removed the previous configured virtual frame buffer with two screens. Then I invoke the orca screen mag and set the zoomer position to the maximum of the screen, removed the source screen and target screen value. After that, it failed to show the desktop within the magnified screen. Are there something need to be corrected? Thanks!
In the code I don't active the Composite support by default. You must start the magnifier with the option "--ignore-composite=0". Do you did this? I forgot to comment this in the thread, sorry!
Yes, I did that with the command "magnifier --ignore-composite=0", but on my machine, I may need composite's header files (in /usr/include/X11/extensions). This led to failure on displaying the desktop in magnified screen. I have asked helps from Sun internal xserver team and waiting for the feedback. Once I have the result, I'll update it here.
Any news Tim? If you are seeing this in your terminal while running with the command "magnifier --ignore-composite=0": "added event source to composite connection" Then the composite support was activated succesfully. If you are seeing this: "this copy of gnome-mag was built without composite extension support" It's probably some problem with the header or lib files. Otherwise is some nasty bug :-)
I applplied your patch( Although the patch fails in trunk, Li Yuan fixed it, I suggest you'd better give your patch based on the trunk code. ) and get the following results. ./magnifier --ignore-composite=0 (magnifier:26386): Bonobo-WARNING **: Assigning a default value to a non readable property 'source-display-screen' (magnifier:26386): Bonobo-WARNING **: Assigning a default value to a non readable property 'target-display-screen' ** Message: added event source to xfixes cursor-notify connection ** Message: added event source to damage connection ** (magnifier:26386): WARNING **: this copy of gnome-mag was built without composite extension support. initial viewport 1280 1024 ** Message: set source bounds to 0,0; 1280,0 (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window (magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window
Carlos, do you know how to solve the problem of "this copy of gnome-mag was built without composite extension support"?
This means configure didn't find composite on your X. You can check config.log, there should be a error with composite or shape. As I know, there are some problems with our X package.
A workaround can fix this issue: Add one line in file X11/Xutil.h "#include <X11/Xlib.h>", and add the INCLUDES path "-I/usr/X11/include". Now it works fine.
(In reply to comment #43) > Carlos, do you know how to solve the problem of "this copy of gnome-mag was > built without composite extension support"? > Do you have the config.log of the configure session that give you the warning "this copy of gnome-mag was built without composite extension support"? Although this is not a gnome-mag problem IMO, the others WARNINGS: "(magnifier:26386): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a pixmap or window" is, so if I can see your config.log I can realize why these are being generated.
Jeff, I realize why the WARNING are happening, so don't worry with this! I will provide a new patch in the next hours applicable to HEAD and the new gmag-events.c files that correct some silly behavior.
Created attachment 78557 [details] new gmag-events.c minor change to correct warnings and a BadDrawable return from a XRaiseWindow call in gmag_events_handler when no -{f,m,h} option is passed to the magnifier.
Created attachment 78558 [details] [review] patch that can be easily applied to HEAD
Carlos, If I don't add the /usr/X11/include in environment variable CFLAG, It still can't be built successfully.
Hi Jeff, could you attach your config.log file?
Created attachment 78970 [details] config.log file: show composite can be found.
It looks the preformance has improved comparing with the previous version using double frame buffer. But I don't know how to change the magnifier ratio? Carlos, could you tell me and I can test again.
Jeff, are you certainly that libXcomposite is installed in the same path of libXdamage and libXfixes? The problem that you are having is that libXcomposite is missing, look at this line of your config.log: ld: fatal: library -lXcomposite: not found If you have X libraries installed in differents paths you can tell configure to search all these paths: #: ./configure --x-libraries="/usr/X11R6/lib /usr/lib /opt/lib" Now, related with the last post, to change the magnifier ration without using Gnopernicus or Orca you could use the control-client application in the test folder, just enter this folder and type: #: ./control-client -z8
Yes, the three files are all under the path /usr/X11/lib.
After applying the patch, at full-screen mode, users can see some blank areas around the real window also be zoomed. It seems control-client doesn't work well on Solaris. It only starts a half-screen window and the zooming doesn't work.
(In reply to comment #55) > Yes, the three files are all under the path /usr/X11/lib. > It's strange that the libXcomposite ins't finded, since the others are. (In reply to comment #56) > After applying the patch, at full-screen mode, users can see some blank areas > around the real window also be zoomed. I don't understand how you are running the magnifier anymore, you succesfully builted it with Composite support or not? The blank areas are normal, since the the mouse tracking logic is leaved to servers (gnopernicus/orca) > > It seems control-client doesn't work well on Solaris. It only starts a > half-screen window and the zooming doesn't work. > control-client until now will always starts a half-screen window, but why the zooming doesn't work?
There have been 17 patches since July. What is the status of committing the xcomposite enhancement for gnome-mag?
And almost 60 comments! I'm only waiting for a positive answer that this is working okay with Solaris, from my POI this is the last impediment.
Carlos, your patch is good. It has improved the performance of gnome-mag comparing with the old version. But I don't know how to change the zoom ratio in full-screen mode yet. You told me to use control-client to do that, but as you said, it can only be used in half-screen.
gnome-mag is just a magnification API. Orca, Gnopernicus or LSR are the programs that effectively control it's options, like zoom ration, invert color, zoomer position, region of interest and the like.
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.
While running gnome-mag on Solaris, xorg process will occupy %30~40% cpu time. Is this a normal case?
Yes Jeff, if I run gnome-mag ignoring COMPOSITE "just --ignore-composite" (sorry to make this :-) xorg process occupy about %15~25% of cpu time, without --ignore-composite xorg occupy 60% of cpu time. This is due the composition being done with XRender, that is not accelerated in most video drivers. Some time ago I put a message in the nvidia forums: http://www.nvnews.net/vbulletin/showthread.php?t=79240&highlight=gnome-mag I plan to use OpenGL to do the composition, but it's not in a short-time...
Hi Jeff, after thinking a little more about this I'm really skeptic if this cpu time is only due the XRender extension... I will look at it with more calm.
In some environment that direct rendering configured successfully, magnifier only occupies up to 20% cpu time. This indicates it is not the problem of magnifier. instead, it's because of without hardware acceleration support.
Hey, this is good to know. The high cpu usage that I get is probably/certainly due the use of Xorg 6.9. Thanks for this feedback Jeff.
Yes; unfortunately it has been reported that this patch causes a regression in terms on latency on some systems with COMPOSITE but without hardware acceleration support. On such systems the user should run the magnifier with --enable-composite=false. I think it may have been Li Yuan who pointed out that there's a way to detect whether direct-rendering is available on a given X server, at runtime. If so, then I suggest that the default for the magnifier should be to only use COMPOSITE if XRender direct-rendering (via hardware acceleration) is available, unless source==target and the two overlap. Tim Miao reports that there is still "fragmentation" when using non-COMPOSITE magnification with the virtual frame buffer. We are not sure if this is specific to XSun's VFB, or if it also can be seen using the XOrg/XF86 'dummy driver'. Last question - is the status of the patches, as currently reported below (accepted but not committed), correct?
I will try to find how to detect if direct-rendering is enabled or not while Li Yuan doesn't post anything, but I think that the user must have the ability to choose if he/she want COMPOSITE or not, maybe we could disable it for now and leave the decision to enable it by default to the distributions, since making the possibility to enable/disable COMPOSITE on the fly will take some time. I don't remember if the "fragmentation" occurs in XOrg/XF86 with the 'dummy driver'. I will test it here when I have time. Yes, the patch status is incorrect, I thinked that using the options that inserted the text in comment #62 changed the patch status.
Carlos, you can use glxinfo, a x11 command to get that information, in the output there's one line "direct rendering", if the value is YES, it means hardware acceleration is enabled.
Specs: Pentium M 2.0 ghz 1 gig ram 7200 rpm hard drive ubuntu edgy (xorg 7 radeon driver) I'm getting around 30-40% cpu usage from what i can tell from the mag/xorg. in comparison to about 10-20 w/o composite. Have different drivers been tested against the compositing? I know compositing effects in general on the desktop are still difficult to bring up with a lot of cards/drivers.
Jeff, glxinfo, AFAIK, only show the information for the GLX extension, that can also use AIGLX that is not direct rendering but still fast! I think that the great issue in performance here is that many drivers doesn't accelerated the XRender extension yet and I don't know if there is a path in the XOrg community about implementing this extension on top of OpenGL. I know that in Xgl, the XRender extension is converted to OpenGL calls, but this is not the case now and probably will not be the case in the short-time. You can see the section "Stacking the Blocks" in the article "The State of Linux Graphics" from Jon Smirl: http://jonsmirl.googlepages.com/graphics.html I also think that a usage around 30-40% cpu is not that creep, since the processor is there for this, be used. And this cpu usage only happens when the user is panning, so this usage is overestimated IMO. I will do some code-refactoring to make possible to enable/disable the extensions on the fly. This way the user can decide if he/she want COMPOSITE or not. I will try to make it available in GNOME 2.18, but don't guarantee anything, only that I will try!
I done a little of profiling here and I saw that the CPU is being spent in gmag_events_handler in the gmag_calculate_windows_clip call, so this is not about the XRender implementation. I will spent some time improving the gmag_events_handler. I also leave the EVENTS_DEBUG defined in the gmag-events.c code that make the X calls be synchonized. This is also degrading performance. When panning like crazy (in vertical split mode) the mag+xorg occupies about 50% without COMPOSITE. WITH COMPOSITE this higher to 60%, being these 10% increased in the XOrg process. Here is the relevant part about the profiles: With COMPOSITE: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 33.34 0.06 0.06 379 0.16 0.16 gmag_events_calculate_windows_clip 22.22 0.10 0.04 1067 0.04 0.04 gmag_events_paint_damaged_windows 11.11 0.12 0.02 gmag_events_handler 5.56 0.13 0.01 1711 0.01 0.01 zoom_region_update_pixmap 5.56 0.14 0.01 649 0.02 0.02 zoom_region_scroll 5.56 0.15 0.01 378 0.03 0.03 gmag_events_paint_windows 5.56 0.16 0.01 92 0.11 0.11 magnifier_transform_cursor 5.56 0.17 0.01 1 10.00 10.00 zoom_region_paint_border 5.56 0.18 0.01 magnifier_main_pan_image 0.00 0.18 0.00 40128 0.00 0.00 gmag_events_paint_window 0.00 0.18 0.00 8918 0.00 0.00 gmag_events_damage_notify_handler 0.00 0.18 0.00 8322 0.00 0.00 gmag_events_add_win_damaged_region 0.00 0.18 0.00 5620 0.00 0.00 magnifier_get_root Without COMPOSITE: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 18.18 0.02 0.02 2108 0.01 0.01 zoom_region_paint_crosswire_cursor 9.09 0.03 0.01 20133 0.00 0.00 gmag_events_damage_notify_handler 9.09 0.04 0.01 5199 0.00 0.00 zoom_region_update_pointer 9.09 0.05 0.01 4429 0.00 0.00 zoom_region_get_type 9.09 0.06 0.01 3242 0.00 0.01 zoom_region_paint_cursor 9.09 0.07 0.01 3015 0.00 0.00 zoom_region_update_pixmap 9.09 0.08 0.01 2108 0.00 0.00 zoom_region_cursor_rect 9.09 0.09 0.01 1134 0.01 0.04 zoom_region_update_cursor 9.09 0.10 0.01 977 0.01 0.01 zoom_region_source_rect_from_view_bounds 9.09 0.11 0.01 1 10.00 10.00 zoom_region_paint_border 0.00 0.11 0.00 11468 0.00 0.00 magnifier_get_root 0.00 0.11 0.00 10856 0.00 0.00 _rectangle_clip_to_bounds 0.00 0.11 0.00 7841 0.00 0.00 zoom_region_clip_to_source The 10% is increased in the XOrg process IMO is because the gmag_events_calculate_windows_clip use X calls that are executed in sync. This explaim why the time spent in these functions in the magnifier process is high. With COMPOSITE and without panning the XOrg process stay with 3-4% of CPU usage, IMO this is because gmag_events_paint_damaged_windows also uses some X calls that are executed in sync. Here is a profile output of the magnifier being executed without panning: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls us/call us/call name 33.34 0.01 0.01 605 16.53 16.53 gmag_events_paint_damaged_windows 33.34 0.02 0.01 134 74.63 74.63 zoom_region_source_rect_from_view_rect 33.34 0.03 0.01 magnifier_main_pan_image 0.00 0.03 0.00 3057 0.00 0.00 magnifier_get_root 0.00 0.03 0.00 1392 0.00 0.00 gmag_events_paint_window Without COMPOSITE the XOrg process almost stay below 1% of CPU usage. Although X have mysteries that are hard to understand, I think that these informations can be a good start to explaim/improve the CPU usage.
I forgot to mention that I did the profiling above with DRI and without DRI and the results were almost the same. (In reply to comment #71) > Specs: > Pentium M 2.0 ghz > 1 gig ram > 7200 rpm hard drive > ubuntu edgy (xorg 7 radeon driver) > > I'm getting around 30-40% cpu usage from what i can tell from the mag/xorg. in > comparison to about 10-20 w/o composite. > > Have different drivers been tested against the compositing? I know compositing > effects in general on the desktop are still difficult to bring up with a lot of > cards/drivers. > I believe that the effects achieved in Beryl/Metacity/Compiz are difficult to bring up with a lot of cards/drivers. These simple thing that we done in the magnifier aren't a great problem IMHO. I will test this code in a computer with an old ATI with 8mb of video memory and see how it works.