Re: [Development] Revisiting high-DPI configuration options

I migrated to Qt from InterViews: http://www.ivtools.org/ivtools/doc/refman3.1/index.html which used floating-point units that could be arbitrarily rescaled, but default to points, like many other standards (e.g., SVG, Postscript). I always found it strange that Qt used integer pixel coords.

Re: [Development] Revisiting high-DPI configuration options

On quarta-feira, 27 de julho de 2016 05:56:52 PDT Nikita Krupenko wrote: > 2016-07-27 4:02 GMT+03:00 Thiago Macieira : > > Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko > > > > escreveu: > >> In Material Design guidelines [1] all font sizes are

Re: [Development] Revisiting high-DPI configuration options

2016-07-27 4:02 GMT+03:00 Thiago Macieira : > Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko > escreveu: >> In Material Design guidelines [1] all font sizes are in scaleable >> pixels (sp). So this size could be multiplied by some factor and all

Re: [Development] Revisiting high-DPI configuration options

Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko escreveu: > In Material Design guidelines [1] all font sizes are in scaleable > pixels (sp). So this size could be multiplied by some factor and all > fonts should scale equally. Maybe we should instead use a size calculated

Re: [Development] Revisiting high-DPI configuration options

2016-07-19 15:58 GMT+03:00 Shawn Rutledge : >> App should remember of couse this setting to restore it back at restart > > How should Qt encourage this? So far we have QSettings, but you need to > define your own setting. And we have not made it easy to scale all fonts >

Re: [Development] Revisiting high-DPI configuration options

On 7/20/16, 5:12 AM, "Development on behalf of Edward Welbourne" wrote: > >Then again, our SVG support is embarrassingly poor, Especially when it doesn’t support clip path. Which I imagine will

Re: [Development] Revisiting high-DPI configuration options

Hello, Everyone and Thiago. >> SVG icons are not shown at all in static builds of Qt, but png icons are >> fine (both icons are taken from resorse file). Static and shred Qt 5.6.1 >> build were done with same config settings except of cause "static". > Remember to force the inclusion of the svg

Re: [Development] Revisiting high-DPI configuration options

On Wed, 20 Jul 2016 10:44:16 -0700, Thiago Macieira wrote: >> Why SVG support of QIcon can not cache rendered result? So re-rendering >> will be as fast as for PNGs. Or you are saying about app startup time? > > Startup. When using SVGs you have to load/parse it into QSvgRenderer and later it

Re: [Development] Revisiting high-DPI configuration options

20.07.2016, 21:08, "Thiago Macieira" : > On quarta-feira, 20 de julho de 2016 21:03:48 PDT Prav wrote: >>  > Startup. >> >>  Approximately how many icons app have to have to see influence on app's >>  startup? > > That depends on the complexity of your SVG icons and

Re: [Development] Revisiting high-DPI configuration options

On quarta-feira, 20 de julho de 2016 21:03:48 PDT Prav wrote: > > Startup. > > Approximately how many icons app have to have to see influence on app's > startup? That depends on the complexity of your SVG icons and how powerful your CPU is. > > I can't speak for business decisions. But however

Re: [Development] Revisiting high-DPI configuration options

> Startup. Approximately how many icons app have to have to see influence on app's startup? >> Also there was idea in this thread earlier that SVG rendering can be done >> much faster ... like in old Opera browser. Why Qt company cann't ask Opera >> to share this part of old Presto engine? They

Re: [Development] Revisiting high-DPI configuration options

20.07.2016, 20:12, "Prav" : > Hello, Everyone. > >>  That's one reason, but there are two more equally, if not more important: >>  1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy >>  applications suffer if they use it. > > Why SVG support of QIcon can

Re: [Development] Revisiting high-DPI configuration options

Hello, Everyone. > That's one reason, but there are two more equally, if not more important: > 1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy > applications suffer if they use it. Why SVG support of QIcon can not cache rendered result? So re-rendering will be as fast as for

Re: [Development] Revisiting high-DPI configuration options

On quarta-feira, 20 de julho de 2016 13:03:03 PDT Prav wrote: > SVG icons are not shown at all in static builds of Qt, but png icons are > fine (both icons are taken from resorse file). Static and shred Qt 5.6.1 > build were done with same config settings except of cause "static". Remember to

Re: [Development] Revisiting high-DPI configuration options

On quarta-feira, 20 de julho de 2016 09:12:53 PDT Edward Welbourne wrote: > I am baffled that anyone does the _x2, etc., approach to icons any more, > when most icons are indeed well-suited to SVG - in most cases, a tiny > SVG, smaller (in file-size) than any one of the many icons it makes >

Re: [Development] Revisiting high-DPI configuration options

> On 20 Jul 2016, at 14:51, André Somers wrote: > > > > Op 20/07/2016 om 14:23 schreef Morten Sorvig: >>> On 19 Jul 2016, at 14:58, Shawn Rutledge wrote: >>> >>> >>> I agree that most apps should have a means of scaling. Control-mousewheel

Re: [Development] Revisiting high-DPI configuration options

> On 20 Jul 2016, at 14:52, Edward Welbourne wrote: > > Morten Sorvig said: >> I’d like us to support both, were an icon/image with more pixels can >> be designated as either “larger” (more content) or “higher resolution” >> (more detail). > > which is why SVG has to be

Re: [Development] Revisiting high-DPI configuration options

Morten Sorvig said: > I’d like us to support both, were an icon/image with more pixels can > be designated as either “larger” (more content) or “higher resolution” > (more detail). which is why SVG has to be the way to go - so you just specify the different levels of detail and let size be a

Re: [Development] Revisiting high-DPI configuration options

> On 20 Jul 2016, at 12:47, Edward Welbourne wrote: > > Michael Zanetti > >> Well, in smaller icons you can have less details than in bigger icons, >> so having multiple icons does make sense. > > That's fair enough - but the thing that makes sense is having more and >

Re: [Development] Revisiting high-DPI configuration options

Michael Zanetti > Well, in smaller icons you can have less details than in bigger icons, > so having multiple icons does make sense. That's fair enough - but the thing that makes sense is having more and less detailed icons, not bigger and smaller ones. Of course, you'll want to use the more

Re: [Development] Revisiting high-DPI configuration options

Heello, Everyone! > Then again, our SVG support is embarrassingly poor, Exactly! For example if you set SVG icon for button and then scale the app with something like QT_SCALE_FACTOR=2 before running the app ... icon will be bluered like this is not SVG! With QT_SCALE_FACTOR=1 icon looks fine.

Re: [Development] Revisiting high-DPI configuration options

On 20.07.2016 11:12, Edward Welbourne wrote: > Prav said: >> Another problem will be with icons. They will scale bad. We are used >> to make icons with versions like _x2, _x3 ... and what we going to do >> if scale factor will be fractional? ... have icons versions like _1.1 >> _1.2 _1.3?

Re: [Development] Revisiting high-DPI configuration options

Hello, Everyone! > Or, come up with another gesture for that kind of zooming. > The devil’s in the details, and we’ve had a proliferation of details over the > last few years. > ... and many other thoughts I wanted to say that right DPI for screen should give only default scale factor for the

Re: [Development] Revisiting high-DPI configuration options

> On 19 Jul 2016, at 10:57, Prav wrote: > > May be Qt need to move accents from getting right DPI to making it user > changeable ... FRACTIONALLY (as a good new practice)! > Like 10-20 % steps ... not just 2,3,4,5. > > I do not see much trend in

Re: [Development] Revisiting high-DPI configuration options

> On 19 Jul 2016, at 10:57, Prav wrote: > > Hello, Everyone! > >> The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to >> focus on two aspects: >>1) Automatic scale factor configuration based on system settings. > There so many debates about this

Re: [Development] Revisiting high-DPI configuration options

2016-07-19 12:48 GMT+02:00 Ulf Hermann : > >> I'm still entirely sure that "let the user decide" was a better way to >> settle how big the page should be, what fonts and colour-schemes to use; >> by all means let the author give hints and suggestions to the >> presentation

Re: [Development] Revisiting high-DPI configuration options

I'm still entirely sure that "let the user decide" was a better way to settle how big the page should be, what fonts and colour-schemes to use; by all means let the author give hints and suggestions to the presentation system, but let the user have the final say. I shall like the look of your

Re: [Development] Revisiting high-DPI configuration options

On Tuesday 19 July 2016 11:57:20 Prav wrote: >> it does not matter what is the DPI of screen. It matter only how >> large PERSON want program font normally be. So I would expect that >> the main intention in developing of apps should be moved toward >> giving the user possibility to scale the

Re: [Development] Revisiting high-DPI configuration options

On Tuesday 19 July 2016 11:57:20 Prav wrote: > Hello, Everyone! > > > The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to > > > > focus on two aspects: > > 1) Automatic scale factor configuration based on system settings. > > There so many debates about this topic and

Re: [Development] Revisiting high-DPI configuration options

Hello, Everyone! > The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to > focus on two aspects: > 1) Automatic scale factor configuration based on system settings. There so many debates about this topic and how to get real DPI for all devices correctly. But I personally

Re: [Development] Revisiting high-DPI configuration options

> On 22 Jun 2016, at 15:30, Michael Zanetti > wrote: > > > * floating point scaling > * different scale factor per window > * dynamically changing scale factor > * some sort of language that allows developers to use virtual sizes, > ideally we'd be able to

Re: [Development] Revisiting high-DPI configuration options

> On 22 Jun 2016, at 15:32, ekke wrote: > > Am 22.06.16 um 14:46 schrieb Morten Sorvig: >>> >> What I have for Android devices are tables like this: (there are various >> sources, see below) >> >> 0.75 - ldpi >> 1.0 - dpi >> 1.5 - hdpi >> 2.0 - xhdpi >> 3.0 - xxhdpi >>

Re: [Development] Revisiting high-DPI configuration options

Am 22.06.16 um 14:46 schrieb Morten Sorvig: >> On 22 Jun 2016, at 10:30, Michael Zanetti >> wrote: >> >> >> >> On 20.06.2016 15:00, Morten Sorvig wrote: >>> Another reason to not spend time on it would be that integer is, or is going >>> to be, the dominating use

Re: [Development] Revisiting high-DPI configuration options

On 22.06.2016 14:46, Morten Sorvig wrote: > >> On 22 Jun 2016, at 10:30, Michael Zanetti >> wrote: >> >> >> >> On 20.06.2016 15:00, Morten Sorvig wrote: >>> >>> Another reason to not spend time on it would be that integer is, or is going >>> to be, the

Re: [Development] Revisiting high-DPI configuration options

> On 22 Jun 2016, at 10:30, Michael Zanetti > wrote: > > > > On 20.06.2016 15:00, Morten Sorvig wrote: >> >> Another reason to not spend time on it would be that integer is, or is going >> to be, the dominating use case. Wayland and Apple is integer, so are

Re: [Development] Revisiting high-DPI configuration options

> On 21 Jun 2016, at 15:24, Samuel Stirtzel via Development > wrote: > > 2016-06-21 14:15 GMT+02:00 Shawn Rutledge : >> >>> On 20 Jun 2016, at 18:09, Thiago Macieira wrote: >>> 160x90 mm is a valid screen size,

Re: [Development] Revisiting high-DPI configuration options

> On 22 Jun 2016, at 10:21, Morten Sorvig wrote: > > >> On 22 Jun 2016, at 09:17, Shawn Rutledge wrote: >> >> >>> On 21 Jun 2016, at 21:26, Thiago Macieira wrote: >>> >>> On terça-feira, 21 de junho de 2016 18:02:05 PDT

Re: [Development] Revisiting high-DPI configuration options

On 20.06.2016 15:00, Morten Sorvig wrote: > >> On 17 Jun 2016, at 14:54, Frank Hemer wrote: >> >> Can you give a hint on what causes these glitches and how to avoid them? >> I'm not talking about general usage of fractional methods for painting here. >> >> For example when

Re: [Development] Revisiting high-DPI configuration options

> On 22 Jun 2016, at 09:17, Shawn Rutledge wrote: > > >> On 21 Jun 2016, at 21:26, Thiago Macieira wrote: >> >> On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote: >>> I think using screen names can be a good match for cases

Re: [Development] Revisiting high-DPI configuration options

> On 21 Jun 2016, at 21:26, Thiago Macieira wrote: > > On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote: >> I think using screen names can be a good match for cases where you are >> sometimes connecting to external screens, provided that the string

Re: [Development] Revisiting high-DPI configuration options

On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote: > I think using screen names can be a good match for cases where you are > sometimes connecting to external screens, provided that the string returned > by name() is unique for each screen. It's not. It's always "DP-1" (it

Re: [Development] Revisiting high-DPI configuration options

> On 17 Jun 2016, at 22:49, Thiago Macieira wrote: > > > Creator is also a bad citizen (worst of all Qt 5 applications I've tested), > but I did not test it again in the scenarios above. When I tested before, I > had to find the right combination that would make

Re: [Development] Revisiting high-DPI configuration options

2016-06-21 14:15 GMT+02:00 Shawn Rutledge : > >> On 20 Jun 2016, at 18:09, Thiago Macieira wrote: >> 160x90 mm is a valid screen size, correspoding to a 7.2" monitor. > > Of course, it’s just suspicious (being a fallback value, apparently), but not

Re: [Development] Revisiting high-DPI configuration options

> 2) Handling fractional scale factors > > This is relevant for e.g. a Windows setting of 250%, corresponding to a scale > factor of 2.5. Presenting a fractional scale factor to the app may cause > graphics glitches, so we round it to the nearest integer, using qRound. > > However,

Re: [Development] Revisiting high-DPI configuration options

> On 20 Jun 2016, at 18:09, Thiago Macieira wrote: > > On segunda-feira, 20 de junho de 2016 14:30:19 PDT Shawn Rutledge wrote: >> Don’t you think there should be a quirks database somewhere (outside of Qt) >> which corrects these cases? The TV model can be

Re: [Development] Revisiting high-DPI configuration options

On segunda-feira, 20 de junho de 2016 14:30:19 PDT Shawn Rutledge wrote: > Don’t you think there should be a quirks database somewhere (outside of Qt) > which corrects these cases? The TV model can be identified, right? > X does it, but that’s not a broad enough scope to cover Wayland. > >

Re: [Development] Revisiting high-DPI configuration options

> On 17 Jun 2016, at 22:49, Thiago Macieira wrote: > >> - Run "./highdpi --metrics", or test with an application. > > See 3 scenarios attached. I'll send a fourth scenario later, when I try at > home with my 45" TV that reports its size as 160 x 90 mm. Don’t you

Re: [Development] Revisiting high-DPI configuration options

> On 17 Jun 2016, at 14:54, Frank Hemer wrote: > > Can you give a hint on what causes these glitches and how to avoid them? > I'm not talking about general usage of fractional methods for painting here. > > For example when drawing to a pixmap (sized for the 'real' screen

Re: [Development] Revisiting high-DPI configuration options

> - Run "./highdpi --metrics", or test with an application. See 3 scenarios attached. I'll send a fourth scenario later, when I try at home with my 45" TV that reports its size as 160 x 90 mm. Software scaling (scenario 3) is achieved with: $ xrandr --output DP-1 --mode 1920x1080 --scale 2x2

Re: [Development] Revisiting high-DPI configuration options

On sexta-feira, 17 de junho de 2016 12:06:06 PDT Morten Sorvig wrote: > It is my impression that getting per-screen logical DPI values from X11 > is difficult. I’d very much appreciate feed back here from users on > various desktops (KDE, GONME, other): Are there settings we can use? We > need an

Re: [Development] Revisiting high-DPI configuration options

Hi Morten, On Friday 17 June 2016 12:06:06 Morten Sorvig wrote: > Hi all, > > After shipping the high-dpi update in 5.6 we’ve gotten several reports > that application scaling does not always come out as intended (see > QTBUG-52318, QTBUG-53416, QTBUG-53500, and QTBUG-54144). I’d like to > take

[Development] Revisiting high-DPI configuration options

Hi all, After shipping the high-dpi update in 5.6 we’ve gotten several reports that application scaling does not always come out as intended (see QTBUG-52318, QTBUG-53416, QTBUG-53500, and QTBUG-54144). I’d like to take a look at this again. There are a lot of different configurations out there