High-DPI TImageList

[Ondřej Pokorný]

Poslední tři dny jsem pracoval na posledním dílu High-DPI skládačky - TImageListu.

Popis: https://bugs.freepascal.org/view.php?id=32967
SVN-branch: https://svn.freepascal.org/svn/lazarus/branches/HiDPIImageList

TImageList teď umí uložit obrázky v různých rozlišeních a komponenty je automaticky dostanou. Programátor se nemusí o nic starat. Když je potřeba rozlišení, které není k dispozici, automaticky se vygeneruje - a pozor, pomocí Mitchelovi interpolace a s podporou alpha-transparence, takže se na to dá i koukat.

+ Dmitry začal pracovat na Cocoa interface (Sphere 10 Software to podpřilo Bounty) - u nás to jede Jen škoda, že ta Lazarus foundation nějak nenaplnila očekávání...

[Ondřej Pokorný]

A ještě screenshot ImageList editoru a demo aplikace pod Linuxem.

[vandrovnik]

Kéž tohle fungovalo i v Delphi... Protože pořád nevím, jak obsloužit situaci, kdy má uživatel víc monitorů, každý jiné dpi, část oken na jednom monitoru, část na druhém...

[98553]

Kéž tohle fungovalo i v Delphi... Protože pořád nevím, jak obsloužit situaci, kdy má uživatel víc monitorů, každý jiné dpi, část oken na jednom monitoru, část na druhém...

Pomoci udalosti OnBeforeMonitorDpiChanged a OnAfterMonitorDpiChanged vyvolanych pri zmene DPI formu (vcetne presunu na monitor s jinym DPI)? Image listu muzes mit vic, nebo je tvorit a plnit z resources za behu (zbytek je o volbe nejblizsi vhodne velikosti).

[Ondřej Pokorný]

Kéž tohle fungovalo i v Delphi...

Třeba si někdo u Embarcadera taky udělá tři dny čas a zapracuje na tom.

Protože pořád nevím, jak obsloužit situaci, kdy má uživatel víc monitorů, každý jiné dpi, část oken na jednom monitoru, část na druhém...

Jak psal Delphin - jedině synchronizovat více TImageListů a při změně rozlišení je přehazovat, popř. generovat nová rozlišení (a zvětšovat/zmenšovat komponenty) - což je vopruz :/ Lazarus/LCL se ti postará o všechno.

[ps]

Poslední tři dny jsem pracoval na posledním dílu High-DPI skládačky - TImageListu.

Super. Osobne imagelist nepoužívam, ale pozriem sa na implementáciu (používam font awesome). Otázka je ako upraviť komponentu aby reagovala na zmenu DPI? Napr. mám potomka TSpeedButton so štandartným Glyph (ktorý sa vygeneruje z toho fontu awesome) vo veľkosti 16 a presuniem form na druhý monitor(ako ináč samozrejme ) a potrebujem zmeniť veľkoosť Glyph zo 16 na povedzme 20. WMSIZE sa vôbec nezavolá, ani AdjustSize.

+ Dmitry začal pracovat na Cocoa interface (Sphere 10 Software to podpřilo Bounty) - u nás to jede Jen škoda, že ta Lazarus foundation nějak nenaplnila očekávání...

Videl som ,že robí Cocoa pekným tempom. Dúfam, že aj tieto ikony vyrieši, a asi spolu s nimi aj tento zásadný bug: https://bugs.freepascal.org/view.php?id=32816 , https://forum.lazarus.freepascal.org/index.php?topic=33215.0

Foundation nejak asi umrela, mohlo to byť celkom fajn. Dať tam nejaké mesačné platby ako má blender foundation a mohlo sa z toho zaplatiť pár programátorov ...

[98605]

Super. Osobne imagelist nepoužívam, ale pozriem sa na implementáciu (používam font awesome). Otázka je ako upraviť komponentu aby reagovala na zmenu DPI? Napr. mám potomka TSpeedButton so štandartným Glyph (ktorý sa vygeneruje z toho fontu awesome) vo veľkosti 16 a presuniem form na druhý monitor(ako ináč samozrejme ) a potrebujem zmeniť veľkoosť Glyph zo 16 na povedzme 20. WMSIZE sa vôbec nezavolá, ani AdjustSize.

Zprava kterou na Windows platforme potrebujes odchytit je WM_DPICHANGED, ale je urcena oknu (formulari), ne potomkum (vizualnim komponentam), natoz pak potomku ktery nema handle. K tomu je jeste treba per monitor DPI awareness povolit.

[98608]

Od Windows 10 muzes odchytit pro vizualni komponenty s handle zpravu WM_DPICHANGED_BEFOREPARENT. K tomu je treba per monitor DPI awareness v2.

[Ondřej Pokorný]

+ Dmitry začal pracovat na Cocoa interface (Sphere 10 Software to podpřilo Bounty) - u nás to jede Jen škoda, že ta Lazarus foundation nějak nenaplnila očekávání...

Videl som ,že robí Cocoa pekným tempom. Dúfam, že aj tieto ikony vyrieši, a asi spolu s nimi aj tento zásadný bug: https://bugs.freepascal.org/view.php?id=32816 , https://forum.lazarus.freepascal.org/index.php?topic=33215.0

Upřímně řečeno jsem ten bug report nepochopil. Vezmu bitmapu 32x32px a kreslím ji na rect 32x32px s retina faktorem 2.0 (t.j. ve výsledku 64x64px). Co jako očekáváte?

[Ondřej Pokorný]

Otázka je ako upraviť komponentu aby reagovala na zmenu DPI? Napr. mám potomka TSpeedButton so štandartným Glyph (ktorý sa vygeneruje z toho fontu awesome) vo veľkosti 16 a presuniem form na druhý monitor(ako ináč samozrejme ) a potrebujem zmeniť veľkoosť Glyph zo 16 na povedzme 20. WMSIZE sa vôbec nezavolá, ani AdjustSize.

Viz http://wiki.lazarus.freepascal.org/High_DPI, "High DPI in Lazarus 1.8 and above" -> zavolá se AutoAdjustLayout/DoAutoAdjustLayout.

[ps]

Viz http://wiki.lazarus.freepascal.org/High_DPI, "High DPI in Lazarus 1.8 and above" -> zavolá se AutoAdjustLayout/DoAutoAdjustLayout.

Vďaka, už som si hovoril, že po večeroch to nebudem riešiť. Asi na to nevidím poriadne 100x som to čítal

[ps]

Upřímně řečeno jsem ten bug report nepochopil. Vezmu bitmapu 32x32px a kreslím ji na rect 32x32px s retina faktorem 2.0 (t.j. ve výsledku 64x64px). Co jako očekáváte?

Aby sa to správalo rovnako ako na inej platforme (Win) teda 32x32 kreslilo na 32x32, alebo aby sa to scalovalo aj na Win (asi horšia varianta) a na správne kreslenie by sa použila iná funkcia.

[Ondřej Pokorný]

Upřímně řečeno jsem ten bug report nepochopil. Vezmu bitmapu 32x32px a kreslím ji na rect 32x32px s retina faktorem 2.0 (t.j. ve výsledku 64x64px). Co jako očekáváte?

Aby sa to správalo rovnako ako na inej platforme (Win) teda 32x32 kreslilo na 32x32, alebo aby sa to scalovalo aj na Win (asi horšia varianta) a na správne kreslenie by sa použila iná funkcia.

Mezi OSX a WIN je jeden zásadní rozdíl: a to ten, že Apple má virtuální rozlišení. T.j. 32x32 se kreslí na 32x32 a je to rozmazané. Jestli to nechceš mít rozmazané, musíš kreslit 64x64 na 32x32. S tím se nedá nic dělat.

TImageList to bude umět ošetřit (pokud rozezná retinu, vezme prostě vyšší rozlišení a nakreslí ho napolovic). Pokud používáš TSpeedButton.Glyph, máš smůlu. To se prostě vyřešit pořádně nedá. Kvůli tomu přidám právě do TSpeedButton a TBitBtn podporu image listu.

[ps]

Hmm tak to by takto šlo, teda keby ten stretchdraw fungoval. Glyph používam len ako storage (TBitmap), kreslím to samostatne. Nemám teraz mac k dispozícii, keď budem mať vyskúšam. A ScaleDesignToForm(32) mi vráti 64 na Retine? A cez Canvas.Line bude mať výšku povedzme 2 px namiesto 1px a nemám šancu inak ako cez bitmap nakresliť 1px čiaru? (Teda ak som to správne pochopil teraz).

[Ondřej Pokorný]

Hmm tak to by takto šlo, teda keby ten stretchdraw fungoval.

Sám si to vyzkouším až se vrátím domů (v únoru), ale od kluků z ScooterSoftware mám echo, že oni právě pro retinu používají StretchDraw.

Glyph používam len ako storage (TBitmap), kreslím to samostatne. Nemám teraz mac k dispozícii, keď budem mať vyskúšam. A ScaleDesignToForm(32) mi vráti 64 na Retine?

Právě že ne. Retina má tu virtuální matici. Takže OSX vrací vždycky 96 DPI = 100%. Pro zjištění retina faktoru musíš použít:

Kód: [Vybrat]

function UiIsRetina: Boolean;
begin
if CurrentOS = osMacOSX106 then
    Result := (BcNSScreen(NSScreen.mainScreen).userSpaceScaleFactor > 1.0)
else
    Result := (BcNSScreen(NSScreen.mainScreen).backingScaleFactor > 1.0)
end;

function TBcCarbonForm.GetIsRetina: Boolean;
var    Window: BcNSWindow;
begin
Window := BcNSWindow(GetWindowRefAsNSWindow);
if CurrentOS = osMacOSX106 then
    Result := (Window.userSpaceScaleFactor > 1.0)
else
    Result := (Window.backingScaleFactor > 1.0)
end;

A cez Canvas.Line bude mať výšku povedzme 2 px namiesto 1px a nemám šancu inak ako cez bitmap nakresliť 1px čiaru? (Teda ak som to správne pochopil teraz).

Jo, tak nějak by to mělo být.

[ps]

Právě že ne. Retina má tu virtuální matici. Takže OSX vrací vždycky 96 DPI = 100%. Pro zjištění retina faktoru musíš použít:

To by šlo, vyskúšam, samozrejme musím riešiť cez ten scaleFactor lebo tiež MacOS má rôzne stupne asi. Otázka je či by sa to nedalo nejak do LCL zapracovať aby sa nemuselo pri tvorbe komponentov priamo pristupovať k platforme (NS*).

[Ondřej Pokorný]

Právě že ne. Retina má tu virtuální matici. Takže OSX vrací vždycky 96 DPI = 100%. Pro zjištění retina faktoru musíš použít:

To by šlo, vyskúšam, samozrejme musím riešiť cez ten scaleFactor lebo tiež MacOS má rôzne stupne asi. Otázka je či by sa to nedalo nejak do LCL zapracovať aby sa nemuselo pri tvorbe komponentov priamo pristupovať k platforme (NS*).

Jo, bude se to řešit.