Bug 370416

Summary:	Zoom function doesn't work properly on HiDPI Display
Product:	[Applications] gwenview	Reporter:	younker.dl@gmail.com <younky.yang>
Component:	general	Assignee:	Gwenview Bugs <gwenview-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	myriam, nate
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description younker.dl@gmail.com 2016-10-10 16:14:39 UTC

When view a image with size 1000*1000 on a HiDPI (4K) display, the zoom function doesn't work as other systems. The actual size of the image when viewing at 100% zoom is about 2000*2000 if the scalefactor of the display is set to 2. 

Gimp handles this correctly with 2.9.4 on the same display, For the image and video output we should ignore the system scalefactor and just render them pixel to pixel. which is the one Mac and Windows do. 

Reproducible: Always

Steps to Reproduce:
1.Open a image with any supported format
2.Change the zoom ratio to 100% 
3. Check the real size of the image showed on HiDPI display, based on the system scale factor, you may get some different size which usually greater than the original image size. 

Actual Results:  
the image with 100% zoom ratio also changed size based on the system scale factor

Expected Results:  
the image part should ignore the system scale factor which just show the size as the image property shows.

This bug happens on most of KDE and QT image and video application, for example, digikam.

Comment 1 younker.dl@gmail.com 2016-10-18 09:42:39 UTC

Just tried xnviewmp. And it shows the image correct, just behave like on others platforms. So this is an issue of our code implementation.

Comment 2 younker.dl@gmail.com 2016-10-27 11:27:02 UTC

I tried to learn QT programming and just tested with QGraphicView, it does show the image based on the scale_factor settings which is not right based on my experience on other platforms. So this may be a Qt bug. but can we do something on our codes to make the behaviour better?

Comment 3 Nate Graham 2017-10-19 18:56:20 UTC


*** This bug has been marked as a duplicate of bug 373178 ***