xournalpp / xournalpp

Xournal++ is a handwriting notetaking software with PDF annotation support. Written in C++ with GTK3, supporting Linux (e.g. Ubuntu, Debian, Arch, SUSE), macOS and Windows 10. Supports pen input from devices such as Wacom Tablets.
https://xournalpp.github.io
GNU General Public License v2.0
11.25k stars 803 forks source link

HiDPI scaling (gtk3) #172

Closed cass00 closed 5 years ago

cass00 commented 8 years ago

Xournalpp (gtk3) doesn't cope with hidpi scaling properly. If I go from normal scaling to hidpi scaling, with say a scaling factor of 2, all objects become twice as big (same zoom level) and lines appear blurry.

I guess Xournalpp is currently not taking this setting into account resulting in this undesired behavior. Any suggestions where the code has to be changed to include this feature? It works fine in Inkscape and Gimp. Maybe these programs can provide a clue on how to handle this scaling factor.

andreasb242 commented 8 years ago

All graphics are kept in a buffer image, so the view is only repainted if you really change, and not on scrolling.

I would guess this buffer is the problem. I have no high DPI device to check...

Look at https://github.com/xournalpp/xournalpp/blob/master/src/control/jobs/PreviewJob.cpp

void PreviewJob::run() { XOJ_CHECK_TYPE(PreviewJob);

=>> Not sure what GTK3 returns here... GtkAllocation alloc; gtk_widget_get_allocation(this->sidebarPreview->widget, &alloc);

=>> Multiple the size with the HDPI Scale? cairo_surface_t* crBuffer = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, alloc.width, alloc.height);

double zoom = this->sidebarPreview->sidebar->getZoom();

cairo_t* cr2 = cairo_create(crBuffer);
cairo_matrix_t defaultMatrix = { 0 };
cairo_get_matrix(cr2, &defaultMatrix);

cairo_translate(cr2, Shadow::getShadowTopLeftSize() + 2,
                Shadow::getShadowTopLeftSize() + 2);

=>> Divide the size with the HDPI Scale? cairo_scale(cr2, zoom, zoom);

cass00 commented 8 years ago

Cheers, I'll look into it when I got time. Btw. I think you can activate the high DPI setting even if you're not having a high DPI device. Everything is just a bit bigger then :)

cass00 commented 8 years ago

As a note: There is cairo_surface_set_device_scale () which was added for this purpose from what I've read (see Cairo ref).

andreasb242 commented 8 years ago

OK, but I have no time next week...

cass00 commented 8 years ago

An easy way to test xournalpp under HiDPI conditions is to use the GDK_SCALE parameter e.g. GDK_SCALE=2 xournalpp -w No need to change any global settings.

cass00 commented 8 years ago

Had a little deeper look into this. It seems there is a bit more work needed. Again, evince might provide the answer to what has to be changed. The relevant commits should be GNOME/evince@a612f809e4e, GNOME/evince@37c13b386a8915 and GNOME/evince@2d3feb111939.

andreasb242 commented 8 years ago

The preview size should also be adapted, but it shouldn’t be that much...

cass00 commented 8 years ago

I made a bit of progress by introducing a scale factor in commit cass00/xournalpp@74c86fbbc2c0d6816. However, not working yet: -scaling of PDF background -strokes not sharp while writing (they become sharp after they are rendered again) -pages are not of equal size for same zoom levels between high dpi and normal (works in evince) -other parts that are affected by rescaling

Furthermore, there is a zoom calibration tab in the preference (the one with the ruler). The scaling factor from there however doesn't seem to have any effect/ is not used. Maybe it would be a good time to integrate this one as well now.

cass00 commented 8 years ago

Managed to get strokes and pdf text (not pictures in pdf) sharp as well. However, I realized that there are tons of other cairo surfaces, for example for imported images or the selection tool. Potentially all of them have to made aware of the display scale. One tricky example is in pixbuf-utils.cpp: surface = cairo_image_surface_create_for_data(pixels, format, width, height, width * size); Simple rescaling doesn't seem to work here. If anyone has some input, please let me know.

andreasb242 commented 5 years ago

Fixed with GTK3 (I tested it now and coulden't see an issue any more, with 125% scaling)

cass00 commented 5 years ago

This is not fixed. In gnome you can only scale by integers. Running GDK_SCALE=2 xournalpp will result in slightly blurry lines. Running GDK_SCALE=5 xournalpp, for example, everything is superblurry. I'm running with Gnome scale factor of 2 on my hidpi tablet, i.e. xournalpp is run with GDK_SCALE=2. A workaround to get sharp lines for me is to run GDK_SCALE=1 xournalpp. In this case the symbols are bit smaller and you can't zoom as much. However, the panel height is still the same as for normal startup. Btw. nice work to finally port this to Gtk3!

andreasb242 commented 5 years ago

Confirmed

cass00 commented 5 years ago

Maybe this is of help: http://wiki.inkscape.org/wiki/index.php/HiDPI

andreasb242 commented 5 years ago

The solution is simple: We need to scale our internal buffer. According to the debug output, I missed a second place where the buffered image gets created or so...

andreasb242 commented 5 years ago

It is partial working, so drawing seems to be Ok now, a little hacked now, but drawing needs also to be scaled... For today I stop working on this.

andreasb242 commented 5 years ago

It's much simpler. We need to disable GTK Scaling on this widget, as Xournal already has Zoom support.

andreasb242 commented 5 years ago

Disable scaling is not possible. :-(

andreasb242 commented 5 years ago

MacBook with Retina screens have this issue to, and are a good device for testing.

andreasb242 commented 5 years ago

For the icon loading probably https://developer.gnome.org/ThemedIcons/ should be used, so the icons are correct scaled (hopefully)

andreasb242 commented 5 years ago

Sorry, wrong comment... Not yet closed...

andreasb242 commented 5 years ago

@cass00 Can you compile with cmake .. -DUNSTABLE_HIGHDPI_FIXES=ON and recheck?

Selection is still low-DPI, Icons also. But if it's generally working, I'll like to recheck and then enable it for all, after that I would create new Issues for the specific tasks.

cass00 commented 5 years ago

Drawing is sharp now, so it seems to work generally. However, rendering seems a bit slow compared to the normal xournal (slight lag between the pen position and the drawn line). Also there is high CPU usage (90% and 70% on two cpus) while the window is visible on the desktop while not drawing.

andreasb242 commented 5 years ago

I have to check the CPU, I tested on a high Power Desktop i7, and probably simple didn't notice that. But maybe it was also #752 which is fixed now.

I'll do a check on a Core2Duo, there I really good feel if we have a speed issue ;-)

andreasb242 commented 5 years ago

I Tested on a Core2Duo L9400 (about 10 Years old), for me it looks good.

I hope you got the Loop issue mentioned in the other Ticket. Else I need more info, what you did.

cass00 commented 5 years ago

The problem persists even with the new patches. What I've found out is that the cpu usage problem does not occur if I compile without the highdpi fixes or if I start with GDK_SCALE=1 xournalpp . Otherwise, there is constant CPU usage of around 150% combined (2 CPUs).

andreasb242 commented 5 years ago

I found it: The PDF Background resolution missmatches, and therefore does a lot of re-rendering. I need to fix this. But this is only with PDF Background, and on my dev machine it's not really much, therefore I didn't see it last time.

andreasb242 commented 5 years ago

I found two bugs, one in the PDF rendering, and one in the High DPI Rendering (size of the image and the source does mismatch, because its e.g. doubled)

No the CPU usage in Idle is 0%, so I hope I found now the bug.

@cass00 Do you ma retest again? Sorry, I hope this is the last time... But I see you are a good tester for this ;-)

cass00 commented 5 years ago

Yes, looks good. Can't see any unusual CPU usage. Tested also with PDF background.

andreasb242 commented 5 years ago

Thank you. I'll bring this to standard soon.

GregDMeyer commented 5 years ago

just wanted to leave a comment that for me it looks like there are still some small problems with HiDPI mode. CPU usage is fine, but some actions are really slow. in particular, when I erase objects with the pen they don't actually disappear for several seconds, and similarly, when I try to draw a rectangle, I don't see anything until several seconds after I release the pen. Not sure what the culprit is but these actions work as expected when I set GDK_SCALE=1.

andreasb242 commented 5 years ago

This is a repaint issue. Please open a new issue, this issue is from 2016....

jackmhny commented 2 years ago

I know I'm six years late but this issue is still top on google for "xournalpp hidpi" so I wanted to help anyone that is having my specific problem. On windows, if you are using the "Scale" setting in display settings, it seems that xournalpp takes the floor((scale/100)), which means that when I had it on 175%, the toolbar was extremely tiny, but setting it to 200% made it readable again. This is likely due to a casting of the windows scale value to gtk, which only accepts ints.

0xpr03 commented 2 years ago

Another bug: every text in the UI menu is blurry. grafik WIndows 10, 200%, 4k high DPI display.