After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 348375 - single-DISPLAY full screen support in gnome-mag
single-DISPLAY full screen support in gnome-mag
Status: RESOLVED FIXED
Product: gnome-mag
Classification: Deprecated
Component: magnifier-utility
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Carlos Eduardo Rodrigues Diógenes
bill.haneman
Depends on: 348203
Blocks: 349087 361788
 
 
Reported: 2006-07-23 01:37 UTC by Carlos Eduardo Rodrigues Diógenes
Modified: 2007-01-25 18:30 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
This patch alter some file to add support for full screen magnification (19.40 KB, patch)
2006-07-23 01:50 UTC, Carlos Eduardo Rodrigues Diógenes
reviewed Details | Review
This is the new file composite-client.c (20.79 KB, text/x-csrc)
2006-07-23 01:52 UTC, Carlos Eduardo Rodrigues Diógenes
  Details
This is the new file composite-client.h (1.65 KB, text/x-chdr)
2006-07-23 01:54 UTC, Carlos Eduardo Rodrigues Diógenes
  Details
make the same changes that the first patch does, with minor modifications (20.47 KB, patch)
2006-08-09 19:40 UTC, Carlos Eduardo Rodrigues Diógenes
none Details | Review
This is the new file composite-client.c improved. This work very better than the older one, but still have some gaps. (24.21 KB, text/x-csrc)
2006-08-09 19:42 UTC, Carlos Eduardo Rodrigues Diógenes
  Details
This is the updated composite-client.h (1.65 KB, text/x-chdr)
2006-08-09 19:43 UTC, Carlos Eduardo Rodrigues Diógenes
  Details
the same effect as the other patches, but with more modifications. (19.03 KB, patch)
2006-08-23 00:08 UTC, Carlos Eduardo Rodrigues Diógenes
none Details | Review
This is the new file gmag-events.c that join the handlers for composite, damage and xfixes notifications. (34.60 KB, text/x-csrc)
2006-08-23 00:09 UTC, Carlos Eduardo Rodrigues Diógenes
  Details
This is the interface to gmag-events.c (1.75 KB, text/x-chdr)
2006-08-23 00:10 UTC, Carlos Eduardo Rodrigues Diógenes
  Details
new gmag-events.c (31.54 KB, text/x-csrc)
2006-11-01 22:02 UTC, Carlos Eduardo Rodrigues Diógenes
  Details
new gmag-events.h (1.69 KB, text/x-chdr)
2006-11-01 22:03 UTC, Carlos Eduardo Rodrigues Diógenes
  Details
patch with more modifcations (29.49 KB, patch)
2006-11-01 22:04 UTC, Carlos Eduardo Rodrigues Diógenes
none Details | Review
minor changes to correct some bugs and adapt to some Bill comments (32.14 KB, text/x-csrc)
2006-11-09 19:25 UTC, Carlos Eduardo Rodrigues Diógenes
  Details
new compositor patch to adress issues pointe by Bill (30.84 KB, patch)
2006-11-09 20:50 UTC, Carlos Eduardo Rodrigues Diógenes
reviewed Details | Review
new gmag-events.c (32.19 KB, application/octet-stream)
2006-12-18 12:42 UTC, Carlos Eduardo Rodrigues Diógenes
  Details
patch that can be easily applied to HEAD (30.42 KB, patch)
2006-12-18 12:44 UTC, Carlos Eduardo Rodrigues Diógenes
committed Details | Review
config.log file: show composite can be found. (75.41 KB, text/plain)
2006-12-28 02:37 UTC, Jeff Cai
  Details

Description Carlos Eduardo Rodrigues Diógenes 2006-07-23 01:37:09 UTC
To support full screen magnification in gnome-mag a some files must be altered and others added, this thread start this process.
Comment 1 Carlos Eduardo Rodrigues Diógenes 2006-07-23 01:50:54 UTC
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).
Comment 2 Carlos Eduardo Rodrigues Diógenes 2006-07-23 01:52:38 UTC
Created attachment 69399 [details]
This is the new file composite-client.c

This is the code that tracks modifications to windows.
Comment 3 Carlos Eduardo Rodrigues Diógenes 2006-07-23 01:54:03 UTC
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
Comment 4 bill.haneman 2006-07-24 20:52:10 UTC
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.
Comment 5 bill.haneman 2006-07-24 20:54:42 UTC
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).
Comment 6 Carlos Eduardo Rodrigues Diógenes 2006-07-24 21:15:14 UTC
(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.
Comment 7 Carlos Eduardo Rodrigues Diógenes 2006-07-24 21:27:12 UTC
(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
Comment 8 Carlos Eduardo Rodrigues Diógenes 2006-07-24 21:30:16 UTC
> 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
Comment 9 Carlos Eduardo Rodrigues Diógenes 2006-08-09 19:40:27 UTC
Created attachment 70573 [details] [review]
make the same changes that the first patch does, with minor modifications
Comment 10 Carlos Eduardo Rodrigues Diógenes 2006-08-09 19:42:20 UTC
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.
Comment 11 Carlos Eduardo Rodrigues Diógenes 2006-08-09 19:43:02 UTC
Created attachment 70576 [details]
This is the updated composite-client.h
Comment 12 Carlos Eduardo Rodrigues Diógenes 2006-08-23 00:08:19 UTC
Created attachment 71416 [details] [review]
the same effect as the other patches, but with more modifications.
Comment 13 Carlos Eduardo Rodrigues Diógenes 2006-08-23 00:09:29 UTC
Created attachment 71417 [details]
This is the new file gmag-events.c that join the handlers for composite, damage and xfixes notifications.
Comment 14 Carlos Eduardo Rodrigues Diógenes 2006-08-23 00:10:27 UTC
Created attachment 71418 [details]
This is the interface to gmag-events.c
Comment 15 Carlos Eduardo Rodrigues Diógenes 2006-08-23 00:15:34 UTC
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.
Comment 16 George Kraft IV 2006-09-19 17:08:58 UTC
One issue, when I click and hold on a window's title bar to drag, then the view is not updated smoothly.
Comment 17 Carlos Eduardo Rodrigues Diógenes 2006-09-20 20:09:16 UTC
(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.
Comment 18 George Kraft IV 2006-09-21 20:18:29 UTC
It seems that the magnifier stops updating the view until I release the drag operation.
Comment 19 Carlos Eduardo Rodrigues Diógenes 2006-10-04 22:30:24 UTC
Thanks for the observation George. It´s really true. Probably this is due the priority that x server events have over updating the screen.
Comment 20 George Kraft IV 2006-10-05 14:37:42 UTC
I recommend that comment 18 be filed as a separate bug after this code gets committed.
Comment 21 Carlos Eduardo Rodrigues Diógenes 2006-10-06 21:13:54 UTC
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.
Comment 22 Jason Grieves 2006-10-11 01:26:13 UTC
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.
Comment 23 Carlos Eduardo Rodrigues Diógenes 2006-10-12 19:53:30 UTC
(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!
Comment 24 Carlos Eduardo Rodrigues Diógenes 2006-11-01 21:59:36 UTC
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!
Comment 25 Carlos Eduardo Rodrigues Diógenes 2006-11-01 22:02:19 UTC
Created attachment 75800 [details]
new gmag-events.c

I made some modification to orgnize better the #ifdefs used throw the code.
Comment 26 Carlos Eduardo Rodrigues Diógenes 2006-11-01 22:03:40 UTC
Created attachment 75801 [details]
new gmag-events.h
Comment 27 Carlos Eduardo Rodrigues Diógenes 2006-11-01 22:04:34 UTC
Created attachment 75802 [details] [review]
patch with more modifcations
Comment 28 Carlos Eduardo Rodrigues Diógenes 2006-11-01 22:07:41 UTC
(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 29 bill.haneman 2006-11-03 09:27:07 UTC
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 30 bill.haneman 2006-11-03 09:41:01 UTC
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
Comment 31 Carlos Eduardo Rodrigues Diógenes 2006-11-09 19:25:35 UTC
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.
Comment 32 Carlos Eduardo Rodrigues Diógenes 2006-11-09 20:50:56 UTC
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.
Comment 33 Carlos Eduardo Rodrigues Diógenes 2006-11-09 20:58:37 UTC
(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 34 bill.haneman 2006-11-22 09:15:00 UTC
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.
Comment 35 Carlos Eduardo Rodrigues Diógenes 2006-11-22 23:15:52 UTC
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.
Comment 36 Carlos Eduardo Rodrigues Diógenes 2006-12-06 23:58:40 UTC
Any news about the tests Bill?
Comment 37 Li Yuan 2006-12-07 00:47:57 UTC
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.
Comment 38 Tim Miao 2006-12-07 07:54:26 UTC
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!
Comment 39 Carlos Eduardo Rodrigues Diógenes 2006-12-07 12:23:53 UTC
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!
Comment 40 Tim Miao 2006-12-08 02:17:50 UTC
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.
Comment 41 Carlos Eduardo Rodrigues Diógenes 2006-12-15 22:04:53 UTC
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 :-)
Comment 42 Jeff Cai 2006-12-18 08:02:46 UTC
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
Comment 43 Jeff Cai 2006-12-18 08:07:56 UTC
Carlos, do you know how to solve the problem of "this copy of gnome-mag was built without composite extension support"?
Comment 44 Li Yuan 2006-12-18 08:27:39 UTC
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.
Comment 45 Jeff Cai 2006-12-18 09:09:13 UTC
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.
Comment 46 Carlos Eduardo Rodrigues Diógenes 2006-12-18 11:26:26 UTC
(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.
Comment 47 Carlos Eduardo Rodrigues Diógenes 2006-12-18 12:09:00 UTC
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.
Comment 48 Carlos Eduardo Rodrigues Diógenes 2006-12-18 12:42:07 UTC
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.
Comment 49 Carlos Eduardo Rodrigues Diógenes 2006-12-18 12:44:22 UTC
Created attachment 78558 [details] [review]
patch that can be easily applied to HEAD
Comment 50 Jeff Cai 2006-12-27 12:58:50 UTC
Carlos, If I don't add the /usr/X11/include in  environment variable CFLAG, It still can't be built successfully.

Comment 51 Carlos Eduardo Rodrigues Diógenes 2006-12-27 21:07:21 UTC
Hi Jeff, could you attach your config.log file?
Comment 52 Jeff Cai 2006-12-28 02:37:16 UTC
Created attachment 78970 [details]
config.log file: show composite can be found.
Comment 53 Jeff Cai 2006-12-28 02:40:39 UTC
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.
Comment 54 Carlos Eduardo Rodrigues Diógenes 2006-12-28 11:29:05 UTC
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
Comment 55 Jeff Cai 2006-12-29 02:01:22 UTC
Yes, the three files are all under the path /usr/X11/lib.
Comment 56 Jeff Cai 2006-12-29 02:23:21 UTC
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. 
Comment 57 Carlos Eduardo Rodrigues Diógenes 2006-12-29 18:49:03 UTC
(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?
Comment 58 George Kraft IV 2007-01-02 15:27:28 UTC
There have been 17 patches since July.  What is the status of committing the xcomposite enhancement for gnome-mag?
Comment 59 Carlos Eduardo Rodrigues Diógenes 2007-01-03 13:40:51 UTC
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.
Comment 60 Jeff Cai 2007-01-04 02:20:43 UTC
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. 
Comment 61 Carlos Eduardo Rodrigues Diógenes 2007-01-04 21:25:34 UTC
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.
Comment 62 Carlos Eduardo Rodrigues Diógenes 2007-01-08 22:17:11 UTC
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.
Comment 63 Jeff Cai 2007-01-12 03:36:46 UTC
While running gnome-mag on Solaris, xorg process will occupy %30~40% cpu time. Is this a normal case?
Comment 64 Carlos Eduardo Rodrigues Diógenes 2007-01-12 21:59:44 UTC
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...
Comment 65 Carlos Eduardo Rodrigues Diógenes 2007-01-16 22:04:34 UTC
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.
Comment 66 Jeff Cai 2007-01-17 11:38:18 UTC
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.
Comment 67 Carlos Eduardo Rodrigues Diógenes 2007-01-17 20:59:02 UTC
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.
Comment 68 bill.haneman 2007-01-22 11:14:15 UTC
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?
Comment 69 Carlos Eduardo Rodrigues Diógenes 2007-01-22 22:10:11 UTC
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.
Comment 70 Jeff Cai 2007-01-23 02:27:35 UTC
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.
Comment 71 Jason Grieves 2007-01-23 03:09:47 UTC
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.  
Comment 72 Carlos Eduardo Rodrigues Diógenes 2007-01-23 11:44:02 UTC
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!
Comment 73 Carlos Eduardo Rodrigues Diógenes 2007-01-24 22:49:51 UTC
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.
Comment 74 Carlos Eduardo Rodrigues Diógenes 2007-01-25 18:30:54 UTC
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.