On Sun, 12 Mar 2023 23:57:49 +0000 (UTC) Anna Cassar via enlightenment-users <enlightenment-users@lists.sourceforge.net> said:
> Hi all, First of all thank you all so much for your helpful replies. My > apologies, my knowledge of how QT apps render is not great yet, but I'm > certainly learning a lot more about it which is really useful! I've done a > bit more testing, and I'm also convinced now that if E has anything at all to > do with the issue then it's probably environment variable related (although I > haven't yet found a guide to help me check whether I have the GTK style > plugins fully installed and set up for E yet). I'm pleased to say that with > your help I was able to get Mixxx to work under Enlightenment! I thought > I'd share details of my tests here in case they are helpful. QT apps appear > to be being given an incorrect device pixel ratio within Enlightenment. I've e doesn't give any ratios... unless you mean ythe xsettings and xrdb xft.dpi settings and there are noty incorrect settings here. it's a number that affects scaling - anything renders to a dpi. e sets this to get apps to scale based on your scale preferences. the goal is to have everyone consistent. that means font X at size Y (eg Sans 10) draws the same everywhere. e sets dpi appropriately to have this happen. if that dpi causes some apps to mis-render, then the problem lies with that app and its toolkit. if i tell you "you have a very low res TV very close to you so it have things sized well i want you to use 50dpi" then... you do that. you use the dpi given if that is how you scale things. this is what e does. it does seem some apps just have never been tested with various dpi values and fall apart. that doesn't make it an e bug - it makes it an app or toolkit bug where it just can't handle some dpi that is given. efl itself doesn't use dpi at all - it does not care. it does tell freetype when rendering a font to use 75dpi because that is the old school dpi that was commonly used when i started writing the font engine for evas, thus "sand 10" in evas and in x would generally look the same. efl doesn't use dpi for scaling - it relies on being given a scale factor. this is used to just go multiple sizes of things, including font size internally as well as size of other items marked to scale. so scale 0.5 means "draw things 1.2 the size as normal" or scale = 2.0 == "draw it 2x the size" or scale 1.378 = draw it 37.8% bigger than the default standard size. qt also supports this kind of scaling - gtk though does not. or more specifically gtk does but ONLY integers. 1x, 2x, 3x. 4x. gtk does not handle fractional scaling (it's been something gtk is working to fix i understand), thus e sets dpi to try force fonts at least to match. but again - this is an app or toolkit bug if it can't handle a given dpi (of course assuming the dpi is sane = setting a dpi of 1 or 0 or 1993204 is probably a bug). > only been able to test this against an old KDE install on a different machine > so far, with an older version of QT; Mixxx dialogs display without issue > there, but this might be unrelated. This problem only affects apps which set > HighDpiScaleFactorRoundingPolicy to PassThrough (such as Mixxx and QT's > DprGadget), and those apps display perfectly when > QT_SCALE_FACTOR_ROUNDING_POLICY=Round is set as an environment variable > (setting QT_SCALE_FACTOR=1.0 results in no change). Within Enlightenment, > Xorg.0.log shows my monitor's DPI defined as (90,88) which is correct; aaah e doesn't set dpi to the correct value. as above. the only way to get gtk AND qt to both scale in any sensible way is to set the dpi to something to make it scale. of course SETTING dpi is wrong, but the older toolkits and apps have it in their head that this is how you scale - you fake the dpi. to me the dpi is a fixed property of a display device and does not change - never should change. it's used only when you want to specifically draw something at a physical size on that display. buty... that's now how these older toolkits think. > xdpyinfo shows 90x88 DPI in resolution; and xrdb shows Xft.dpi as 90 (set > in .Xdefaults) so I _think_ these are all as they should be. However, > DprGadget shows a device pixel ratio of 0.9375 (which is 90/96), and all > other widgets are not displayed at all! This is the same problem I was seeing > in Mixxx. If I set QT_SCALE_FACTOR=96/90, DprGadget _does_ work well, and > displays a device pixel ratio of 1.0, along with a native logical DPI of 90, > but, oddly, a QWindow DPI of 96! If the pixel ratio within QT under i suspect this rounding feature might be like rounding down? and thus a dpi like 90/96 rounds down to 0 by qt and thus falls apart totally. thus would be a qt bug though... :) > Enlightenment is based on a DPI of 96, alongside the correct DPI of 90 for my > system, I've no idea at all yet where that's coming from. Within plain X, > xrdb returns _nothing_ under xterm, and xdpyinfo still shows 90x88 DPI. e sets both xft.dpi xrdb and xsettings dpi. these are set based on your selected scale factor and "application base dpi" (look in advanced scale settings in e). e sets these 2 dpi values to base dpi * scale factor. e.g. if you use scale 1 then it sets it to 75. this achieves the above consistency (for me at least) and pixel for pixel regular gtk, qt and efl apps draw the same font at the same size. you can adjust this base dpi if you want. advanced feature of course :) this will cause gtk and qt apps then to scale differently - how they do it is up to them but e just sets the dpi. > There, DprGadget shows a pixel ratio of 1.0, and all widgets display > perfectly (as they do if I set the "Round" rounding policy for QT under > Enlightenment, again resulting in a device pixel ratio of 1.0). In any case, > Mixxx is now fully usable if I make sure it doesn't pass through the DPI > scale factor! I'm really happy about this, although I would be interested to > find out whether it's Mixxx, QT, GTK or me which is actually at fault. :-) > Thanks so much for all your help, Anna a combo of mixx and qt. i suspect removing that rounding factor logic will suddenly fix it. i think its actually a qt feature and code path that is kind of broken and some apps like mixx (and freecad) request this feature not realising it is kind of broken... :) personally - an app that segfaults on start (probably because it can/'t find jackd as i use pulse) without a sensible error dialog or some fallback hints to me that the developer is not polishing things as well as they could which makes me suspect other things may not be as nicely polished. :) > On Sunday, 12 March 2023 at 23:09:54 GMT, Carsten Haitzler > <ras...@rasterman.com> wrote: > On Sat, 11 Mar 2023 19:36:56 +0900 Masaru Nomiya <nom...@lake.dti.ne.jp> > said: > > > Hello, > > > > In the Message; > > > > Subject : Re: [e-users] Having issues getting mixxx to work > > Message-ID : <20230307054350.c86a5fea5a95729ab0bf6...@rasterman.com> > > Date & Time: Tue, 7 Mar 2023 05:43:50 +0000 > > > > [CH] == Carsten Haitzler <ras...@rasterman.com> has written: > > > > CH> On Mon, 6 Mar 2023 21:34:18 +0000 (UTC) Anna Cassar > > CH> <anna_cassa...@yahoo.co.uk> said: > > > > CH> e sets xsettings to tell apps that read these to uses some > > CH> specific fonts, theme, dpi etc. - i've seen qt mess up badly when > > CH> theme is set AND the qt style plugins are not there. it doesn't > > CH> fall back gracefully. not qt5 style. qt5 style plugins. the > > CH> plugins is the important bit - the thing that provides some > > CH> plugin for qt to properly do this. > > > > CH> 5:32AM ~ > pacman -Q | grep styleplugins > > CH> qt5-styleplugins 5.0.0.20170311-35 > > > > CH> all i see is mixx segfault. probably because it can't connect to > > CH> jack. not very graceful. it does it even in a wm-less xephyr. > > > > CH> e also sets 2 env vars: > > > > CH> QT_QPA_PLATFORMTHEME=gtk2 > > CH> QT_STYLE_OVERRIDE=gtk2 > > > > CH> this tells qt to use the gtk2 style to do theme stuff. you could > > CH> unset these in a terminal and run mixxx from there and see. > > > > CH> it might mess up if it doesn't like the dpi set - but then that'd > > CH> be it's problem for not rendering at that dpi to scale correctly > > CH> - regardless of the value. either ignore the dpi or use it as > > CH> given. don't use it then fall over if the value isn't one you like. > > > > I think everything written here is out of line. > > > > I mean, I have no problems with mixxx look and feel on any WM on my > > PC, not just enlightenment, but twm, Plasma5, Gnome, e16, and icewm. > > > > I can only assume that there must be a problem with the build of > > enlightenment.... (_ _? > > that's not how x11 works. mixx is in charge of rendering its own content. it > does so directly using x11 protocol to its own window. e just composites the > resulting bitmap. the "it only happens in e - thus i blame e" is a bit of > continuing false logic almost always from people who have no idea how apps, > toolkits, wm's, x11 or compositors work. > > your logic is flawed. e is not involved in rendering, it's the client side > that does that. at worse e setys the env vars to tell qt to use a gtk > handling style plugin to make themes match between gtk and qt falls over > badly when it can't find the gtk style plugin and qt or e sets dpi to > something qt/mixx does not like. but both of these would be bugs on the > client side. > > i've explained that e sets some env vars to encourage qt to use the gtk style > plugin so it will inhrit theme information from gtk. if qt completely falls > over as a result of this, then qt is not very good at handling its own errors. > there is no way for e to know if qt can or cannot handle gtk themes. there is > no mechanism to find out. if it's this then unset the env vars OR install the > style plugins as i mentioned so qt stops failing poorly. it could also be that > e set a dpi value lower than qt5/mixx would expect. there is nothing wrong > with setting a low dpi. if you have a low dpi screen then this is exactly > what you want. if this is the issue the problem is STILL in qt5 or mixx. it's > not e's fault or problem that it sets a lower dpi value. you can find out the > above by unsetting the above env vard then running mixx from that shell. you > can find out if its xsettings dpi by disabling e's x settings feature - > logging in again to clear everything out and running mixx (also try both with > env vars gone an d x settings not there). but just saying "it's e's fault" is > not even trying to narrow down what on qt/mixx's side the problem is as the > problem *IS* over there as e has NOTHING to do with the rendering of an x11 > client - only the final compositing of the resulting image. > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - ras...@rasterman.com > > > > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
