Closed cass00 closed 5 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);
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 :)
As a note: There is cairo_surface_set_device_scale ()
which was added for this purpose from what I've read (see Cairo ref).
OK, but I have no time next week...
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.
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.
The preview size should also be adapted, but it shouldn’t be that much...
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.
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.
Fixed with GTK3 (I tested it now and coulden't see an issue any more, with 125% scaling)
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!
Confirmed
Maybe this is of help: http://wiki.inkscape.org/wiki/index.php/HiDPI
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...
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.
It's much simpler. We need to disable GTK Scaling on this widget, as Xournal already has Zoom support.
Disable scaling is not possible. :-(
MacBook with Retina screens have this issue to, and are a good device for testing.
For the icon loading probably https://developer.gnome.org/ThemedIcons/ should be used, so the icons are correct scaled (hopefully)
Sorry, wrong comment... Not yet closed...
@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.
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.
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 ;-)
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.
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).
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.
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 ;-)
Yes, looks good. Can't see any unusual CPU usage. Tested also with PDF background.
Thank you. I'll bring this to standard soon.
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
.
This is a repaint issue. Please open a new issue, this issue is from 2016....
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.
Another bug: every text in the UI menu is blurry. WIndows 10, 200%, 4k high DPI display.
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.