xorg 100% cpu while using xournal

Bug #657783 reported by Emiliano Bonassi on 2010-10-10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Won't Fix
libgnomecanvas (Ubuntu)

Bug Description

Binary package hint: xournal

After few pages taking notes on xournal it's impossibile to write.
You have to wait some second to see appear what you write.
I've see that when my mouse or my pen was over xournal window xorg cpu usage start to grow exponentially till saturate my cpu.
Architecture: amd64
DistroRelease: Ubuntu 10.10
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100406.1)
Package: xournal 0.4.5-2build1
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic
Tags: maverick
Uname: Linux 2.6.35-22-generic x86_64
UserGroups: adm admin cdrom dialout dip fax floppy fuse lpadmin plugdev sambashare tape video

Emiliano Bonassi (benazhack) wrote :

ubuntu is 10.04 LTS x64 and xournal is 0.4.5-2, my platform is a 2710p with l7700 intel processor.

Leo Arias (elopio) wrote :

Could you please use xrestop to verify if xournal is the program consuming the cpu?

Thanks for your report.

Changed in xournal (Ubuntu):
status: New → Incomplete
Emiliano Bonassi (benazhack) wrote :

I believe xournal is the problem.
After writing one page xrestop tells that xournal is using 1000 GCs (other col are similiar to others app) and i've tried to open an old xournal file of 50 pajes..after boil up my laptop xournal opened that (never happened) and xrestop tells that xournal is using 783000 GCs...
i've looked for GCs meaning but the nearest info i've found is GarbageCollectors...
anyway this morning i've upgraded to 10.10 and i'm still having the same issue...
it's a problem cuz i've to prepare nuclear physics exam and i don't want to print 500 and more slides :D.
if i can i give u more infos.

Emiliano Bonassi (benazhack) wrote :

xrestop output of xournal with a documents of 6 pages

2 - Xournal - Parità.xoj ( PID: 8975 ):
 res_base : ox7e00000
 res_mask : ox1fffff
 windows : 7
 GCs : 69321 <<----------------------------
 fonts : 1
 pixmaps : 20
 pictures : 36
 glyphsets : 2
 colormaps : 0
 passive grabs : 0
 cursors : 4
 unknowns : 14
 pixmap bytes : 140312
 other bytes : ~1666240

Leo Arias (elopio) wrote :

I think that GC means graphic context. But I'm not sure.

If you could upload somewhere that file that's causing you troubles I can try to confirm the issue on my machine.
I have some highlighted PDFs with 500 pages or more and they work for me without issues. And I have some small xournal files with 4 to 7 annotated pages and they work ok too.

pura vida.

Emiliano Bonassi (benazhack) wrote :

testing file..my QM notes on symmetries.

Emiliano Bonassi (benazhack) wrote :

maybe xorg-intel driver?? tomorrow or later i'll try to force xorg vesa and see what's happen. oK?

Leo Arias (elopio) wrote :

I couldn't open the file you attached. It got stuck and after a few seconds it got to the top of xrestop:

5200000 4 789669 1 3 17 9K 18509K 18518K 12842 Xournal -

So I'll mark this bug as confirmed.

elopio@tangamandapio:~$ aptitude show xournal
Package: xournal
State: installed
Automatically installed: no
Version: 0.4.5-2build1

Changed in xournal (Ubuntu):
status: Incomplete → Confirmed
Leo Arias (elopio) wrote :

Oh, I forgot. Please run:
apport-collect 657783

This will add a lot of useful files to the report.

tags: added: maverick

apport information

tags: added: apport-collected
description: updated
Emiliano Bonassi (benazhack) wrote :

done..should u change also the importance of the bug...u cannot use the program with this bug..u can only draw some line and then..spuff...affect also 10.04

description: updated
Leo Arias (elopio) wrote :

I can not do that. We now have to wait for a member of the bugsquad to set an importance and mark the bug as triaged.

Denis Auroux (auroux) wrote :

I can reproduce the bug with your files on my system. I don't see anything wrong with your files. Hence it's a real bug.

I believe this is caused by the "pressure sensitivity" option, which causes the rendering to become much more complicated, and by issues in the rendering libraries (libgnomecanvas and libart) used by xournal -- xournal is asking them to render several million antialiased polygonal curves, each with its own width parameter, and they seem to become completely overwhelmed and hog X resources in a way that's hard to believe.

I hope that, if you stop using the "pressure sensitivity" option, you'll be able to get much further (though things will eventually slow down again as the volume of notes gets large). Due to the inefficiency of the rendering libraries, until xournal gets completely rewritten for performance you should probably have no more than 20-ish pages of handwritten notes in your document, and even much less if using pressure sensitivity.

If you e-mail me so I know how to reach you, I can send you a version of Simmetrie.xoj with all the stroke width information removed, it loads successfully and reasonably fast (still a bit slow, but hey it's 50 pages).

QUESTION: is this indeed a new bug for you, i.e. were you previously able to work fine with this document and others of similar size with variable-width strokes? If so, I'm assuming it must be an issue in either the libraries or the X server, because absolutely nothing has changed in xournal's rendering code in the last year or so.


Emiliano Bonassi (benazhack) wrote :

I cannot reproduce the bug now, seems to be disappeared.
I see the slowness now only with xrestop running.
Last day i've upgraded some packages of ubuntu but they were only kernel and not Xorg related.
Remember that when the "bug" happened only moving cursor over xournal let xorg process saturate cpu resources.
So i agree with ur last sentence, i believe is X org related but i'm not so expert to diag where is the problem.
I forgot, i alway worked with documents of more than 200 pages.

Emiliano Bonassi (benazhack) wrote :

Cannot write more than 3 pages, it's impossible to take notes.
A lot of my friends get this nasty issue, please someone solve this bug.

Timo Kluck (tkluck) wrote :

I am pretty sure the problem lies in Gnome Canvas. It allocates a gdk graphics context for every stroke, even when they are not visible. The attached patch to libgnomecanvas alleviates this problem: xournal will still be (very) slow in continuous page mode, but not in single-page mode.

I am not saying this is a good patch; it may break other programs depending on libgnomecanvas. You should regard this as a proof that the problem is actually where I'm saying.

Please test & confirm.

affects: xournal (Ubuntu) → libgnomecanvas (Ubuntu)
Timo Kluck (tkluck) wrote :

Here's an even easier fix: as far as I can tell (by looking at a small sample of the render() methods), the anti-aliased version of GnomeCanvas does not need the items to be realized at all. Please test the new attached patch instead of my earlier try. I haven't run into any trouble with it when using Xournal. I will try to get some testing with other applications using an anti-aliased canvas.

Timo Kluck (tkluck) wrote :
tags: added: patch
Changed in libgnomecanvas:
importance: Unknown → Medium
status: Unknown → New
Changed in libgnomecanvas (Ubuntu):
importance: Undecided → Low
Emiliano Bonassi (benazhack) wrote :

I'm very disappointed to say that there was no solution, i cannot write more than 4 pages , after that xournal become unusable.
None of the patch works, some i ask if there was a solution that consist of the replacement of libgnomecanvas with another library that do the same work.
If not won't be possible, there was some kind of alternatives to xournal on linux?
I don't want to return to windows to use my tablet.

Changed in libgnomecanvas:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.