Hirdetés
-
Új gyártástechnológiai útitervvel állt elő a TSMC
ph 2027-re érkezhet meg a vállalat 1,6 nm-es eljárása, de a sztárok inkább az olcsóbb node-ok lesznek.
-
Mozgásban az Arena Breakout: Infinite (PC)
gp A korábban csak mobilokra/tabletekre megjelent FPS hamarosan PC-n is elérhető lesz.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
Új hozzászólás Aktív témák
-
Tigerclaw
nagyúr
Tenyleg, a W11-ben a skalazasi rendszer fog valtozni valamit?
Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.
-
ledgeri
nagyúr
Egy "kép" szócska igencsak elkéne a címbe...
// #ublockO-HardMode // anti-blockadblock-er // PH! új arculat: 1/ 500 // szeksziboj -nálam van egy pirospontod! // Találtam sárga fényű lézert! (kézit, ceruzaelemest) https://youtu.be/XQnmMjYHgcM //
-
LGG555
aktív tag
Aki 144Mhz -en játszik online játékot az nem hiszem hogy laptopon tolja, így szerintem ez hordozható gépeken elég felesleges.
Konfig:MSI MEG B550 UNIFY-X, Ryzen5 5600x, G.Skill 16GB 4000Mhz, Radeon VII, Seasonic Snow Silent 550w..
-
#72042496
törölt tag
"Az optimális az lenne, ha a felhasználó a játékok előtt mindig kiválasztaná például a 144 Hz-et, majd szimpla asztali munkavégzésnél visszaállna 60 Hz-re."
Ez messze lenne az optimálistól, mert asztali munkavégzésnél is sokkal jobb 60 helyett a 120 Hz (60/120-at írnak a DRR kapcsán).
"A fentieknél is fontosabb, hogy az adott program felkészíthető a DRR-re, vagyis magában az alkalmazáson belül is meg lehet szabni olyan tényezőket, amikor a frissítési frekvencia ugorjon a maximális értékre."
Ez már jobban hangzik, bár kézenfekvőbbnek tartanám azt megszabni, hogy mikor NE ugorjon a maximális értékre. Attól tartok, hogy lesz hozzá ötvenezer kapcsoló amelyikekkel mindent be lehet majd álíltani csak azt nem, hogy statikus képnél 60 Hz legyen, amúgy 120.
[ Szerkesztve ]
-
vicze
félisten
Ha egy alkalmazás modern API-kat használ 100%-osan jól fog skálázódni, ha nem akkor ahogy esik úgy puffan, az MS ezzel az ég világon semmit nem tud kezdeni, ezt vagy megéritek egyszer és minden korra vagy életed végig fogsz nyavajogni.
Egy ősrégi Win32 alkalmazást konkrétan lehetetlen hogy az OS oldja meg a skálázását, mert úgy vannak megírva, hogy minden méret függő egymáshoz és nem pixelekhez.
Ülj le nyiss meg egy régi IDE-t és kezdj el GUI-t tervezni Win32 elemekkel, a világ legjobb mókája. És akkor nem említettem a 100%-ig custom GUI-s alkalmazásokat amik mindenből egyedi izékat használnak, sok szerencsét azt skálázni. -
Komplikato
veterán
Elvileg rá lehet kényszeríteni alkalmazásokat, hogy DE a windows skálázás beállításait használja a program csak hackelni kell hozzá XML fike-t. Minden egyes renitens programhoz, egyenként. Valahol láttam erre példát a szintén "kiválóan" elkészített Adobe programjaihoz.
"Figyelj arra, aki keresi az igazságot és őrizkedj attól, aki hirdeti: megtalálta." - (André Gide)
-
ddekany
veterán
Amikor nem állapítható meg, hogy játék fut, miért nem inkább abból indul ki, hogy ha nincs tápra dugva, akkor 60 Hz, amúgy meg maximális?(Aztán lehet betenni finomhangolást, hogy mondjuk 70% akku töltés fölött mindig maximális.)
[ Szerkesztve ]
-
sb
veterán
Ez oké, de én pl. kifejezettem az MS programjairól írtam.
Ott nekik kellene ezt megtenni és képtelenek rá évek óta.Egy Office vagy SQL Management Studioban egy sz*ros listboxot nem tudnak megcsinálni. Egyik módban homály a szöveg (és emlékeim szerint az a default... nem is értem mikor a fontkészletek aztán tényleg 20 éve skálázhatóak), a másikban normálisan felskálázza de kilóg a boxból mert képtelen hozzánagyítani.
Ehhez képest egy Firefox nemhogy statikusan tökéletes de ha áthúzod egy 100%-os nagyítású monitorról a mellérakott 125%-osra azt is csont nélkül kezeli.
Egyébként meg abban is van igazság, hogy az API is az MS gondja. Menük, toolbarok, felületek felépítése normál esetben csak ezeken a szabványos és os által támogatott módokon mehetne és ehhez ragaszkodniuk kellene. Ezek platformszinten ragadnak meg mindenki agyában mint hátrány... mivel áttételesen végül is teljesen platformfüggők is.
[ Szerkesztve ]
-
sb
veterán
Biztos jobb de ez a kompromisszumról szól...
Lehet, hogy desktopra elég 75 vagy 90Hz is és így tovább bírja az akksi. A cpu sincs fullra járatva ha nem kell, elvnek jobb ez, mint a brute force kimaxolás.Amúgy évek óta kedvencem az Intel IGP driverben Dell Latitude-on, hogy akksin és/vagy power saver módban 40Hz-re vált vissza a kijelző. Kerestem pár percig, hogy mégis mi történt az egérrel/USB frekivel.
@LGG555
Nyilván nem teljesen ugyanaz a vga van a notikban, de egyrészt felnőttek a feladathoz ugyanúgy, ahogy a cpu-k és a noti hűtések is mára. Ez 1-2 éve még nem így nézett ki, ma meg megkapod a desktop high end -10-20%-ot simán. Az 1-2 évvel ezelőtti desktopot meg kb. üti is akár.
Emellé a mai vga árak mellett gyk. annak az áráért adnak a teljes gépet, a már említett erős desktop cpu-t kiváltó procival és mindennel együtt. Kijelzőkből meg tényleg sok a 120-144Hz-es már. Én nem játszom, sima notikat keresgéltem mostaniban, de szembe jöttek nem sokkal drágábban ilyenek is és elgondolkodtatott, hogy majdnem a közepes desktop árán kijön egy ilyesmi noti. Mondjuk 5600/3060/90-144Hz és akár FHD feletti felbontás.
Szóval van realitása. -
zseko
veterán
Fórumolvasáshoz meg elég lenne az 1Hz is, azzal aztán mennyi energiát lehetne megspórolni!
HR24.hu
-
ddekany
veterán
"Egyik módban homály a szöveg (és emlékeim szerint az a default... nem is értem mikor a fontkészletek aztán tényleg 20 éve skálázhatóak), a másikban normálisan felskálázza de kilóg a boxból mert képtelen hozzánagyítani."
A régi API-val is támogatott a DPI skálázást, de van egy nehezen kezelhető alapvető gond vele, amit semmi amit régen láttam nem kezel le automatikusan. A szöveg nem pont úgy skálázódik, mint minden más, a pixelrácshoz igazítós trükkök miatt. Tehát mondjuk 1.5x-esére kéne nagyítani a monitor DPI-d alapján, és a legördülő vagy gomb szélessége 1.5x-ös is lesz (ha jól dolgoztak a programozók), eddig csodás. Ám a szöveg szélessége mondjuk 1.7x-es lett (és a pontos szám a fonttól, stílustól, és tartalomtól is függ), és lehet, hogy nem fér már bele a csak 1.5x-ös legördülőbe vagy gombba, és le lesz vágva a széle. Ha viszont azt mondod a Windows-nak, hogy hazudja azt az alkalmazásnak, hogy szokványos alacsony DPI-s a monitorod van, akkor pont úgy lesz minden, ahogy régen a készítők letesztelték, szóval minden kifér stb. Miután a komplett ablak így (alacsony DPI-t feltételezve, tehát kis felbontásban) meg lett rajzolva (a szövegek is), utána átméretezi neked a Windows, mint egy sima képet. Ettől persze az egész homályos lesz, így a szöveg is.
Mit lehet tenni a készítőknek? Régen azt lehetett, hogy az elterjedtebb skálázásokban is letesztelted az alkalmazásodat, és kézzel igazgattál rajta ahol kell. És akkor ezt még szorozd fel a támogatott nyelvekkel. Nyilván kb. senki nem tette meg. A másik, hogy átálnak egy modern API-ra, amire gondolom elég nagy munka. Ott viszont alacsony DPI-s monitorokon kicsit homályosabb lesz a szöveg, mert nincs pixelrácsra igazítás olyan szinten, hogy az elszabotálná a szöveg szélesség skálázódását. Szóval régen nem is lett volna ideális választás.
[ Szerkesztve ]
-
#16939776
törölt tag
Szerintem földre fekve, a hátamon fetrengve fogok röhögni, amikor kiderül, hogy a 60 és a 144Hz-el hajtott panel között a meghajtás miatt lesz fényerőérzet vagy képélességi eltérés, vagy a ha a mozdulatnak a felénél veszi észre magát, és ugrik egyet a kurzor a ~10ms válaszidő eltérés miatt.
Az ötlet jó, szigorúan az üzemidő javítására, de a kivitelezést meglátjuk mennyire lesz OK, egy valódi véges képességű hardveren végrehajtva
[ Szerkesztve ]
-
ddekany
veterán
Ezzel amúgy pár évtizedre meg is állt a DPI gond megoldása, mert el fog tartani addig, amíg természetes módon kikopik miden a használatból, amit nem eleve már skálázódást támogató keretrendszerrel készítettek. Mert kényszer nincs az átírásra, mivel a régi API támogatása marad, annak megszenütetése nem reális.
Amúgy azt már megoldották, hogy ha egy szokványos és egy high DPI-s monitor közt átmegyek egérrel, akkor ne rossz helyen lépjen be? Mikor utoljára volt ilyen kiépítéssel dolgom, ott a pixel szerinti távolságot tartották meg a képernyő szélétől, nem a fizikai távolságot, ami nem kicsit béna.
[ Szerkesztve ]
-
sb
veterán
Az Office tök homály volt sajnos.
De a kérdésnem ez, hanem, hogy mit jelent, hogy "legacy". Akkor most mi van? Mi a sorsa? Kinek kéne lépnie? Mire várunk?
Még mindig az MS-ről beszélünk...@ddekany
Azt értem amit mondasz, a TT fontok több méretben tárolódnak tudtommal és nem feltétlen teljesen arányos a nagyítás (szélesség) minden esetben.
De:
1. Én a fenti eseteknél pl. magasságról beszéltem. Az egy egszerű arány és annak legalább stimmelnie kéne ha utána hagyjuk is szabadon a szélességet, mint kezelhetetlen tényezőt...
2. MS programokról van szó! Könyörgöm. Ha valakinek a neve alatt fut ilyen amit 10+ éve látod mennyire szar akkor még van miről beszélnünk?
Közben egy FF-et áthúzok egyik nagyítási ablakról a másikba és minden a helyére ugrik. Átméreteződnek a fontkészletek és nem szarul, hozzá méreteződik a menü. Nem lóg ki, nem lóg le, nem lesz homályos. Se a TT, se az AA/ClearType nem cseszi szét. -
ddekany
veterán
Nem tudom magassággal mennyire szívózott a szöveg átméreteződés (nagyon rég fejlesztettem már ilyesmit), de lehet, hogy az is genyó.
MS és modernizálás... Nekik nem kell, mert ők tudják, hogy saját meguk alol nem rugják ki a legacy-t. Ennek mondjuk legszebb példája a Windows RT volt, ahol nem használhattál Win32-t, kivéve persze az MS-t akik lényegében egy az egyben rádobták a hagyományos Intézőt és Office-t. DPI skálázódás meg, ja hát... jó az a parasztnak, gondolták.
[ Szerkesztve ]
-
vicze
félisten
Kb. 2018-óta nem tapasztaltam skálázási problémát Office-szal.
Az egyetlen dolog ami volt, hogy ha gyakran válottál felbontást az appot újra kellett inditani, de ezt se tapasztaltam jó ideje. 3 felbontáson 4 különböző skálázással használom folyamatosan, napi szinten dinamikusan többször állítva. (O365 current channel)Legacy minden ami Win32 és nem Store app. Ez a Win ököszisztéma 99%-ka szerintem.
SSMS egy Visual Studio csökevény, tehát pont akkor fog skálázódni ha az, kb. soha... -
ddekany
veterán
Van még a WPF is, ami bőven store (UWP) előtti, és rendesen skálázódik. Mondjuk elsősorban C#-os fejlesztéshez találták ki, ami eredetileg C++-os projekteknél gondolom visszatartó erő lehet.
Office lehet hogy már kikupálódott ilyen téren. A bizonytalanság, hogy lehet hogy valami amit használsz nem fog jól működni eléggé visszafoghatja a Windows világban a magas DPI-s monitorok elterjedését. Népi bölcsességgé vált, hogy inkább vegyél hagyományos DPI-set, azzal kevesebb a gond. Én amúgy mostanában már megkockáztatnám... max kicsit le lesz csippentve itt-ott a szövegből, de legalább mindenhol máshol szebb az írás. Ha valamiben ami gyakran kell homály módba kell visszaváltani, mert használhatatlanná csúszik szét, vagy pl. mert egyáltalán nem skálázódik, ezért mikroszkopikus lenne... az akkor erős balszerencse.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- PlayStation 4
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Autós topik látogatók beszélgetős, offolós topikja
- Ukrajnai háború
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- EA Sports WRC '23
- Vodafone mobilszolgáltatások
- Milyen TV-t vegyek?
- Egérpad topik
- További aktív témák...
- BESZÁMÍTÁS! GIGABYTE WindForce 2X GTX 960 4GB GDDR5 videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! SAPPHIRE RX 460 2GB GDDR5 videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! Gigabyte AORUS MASTER RX 6800XT 16GB GDDR6 videokártya garanciával hibátlan működéssel
- GIGABYTE RX 6700 XT 12GB GDDR6 AORUS ELITE Eladó! 102.000.-
- PowerColor RX 6700 XT 12GB GDDR6 RED DEVIL Eladó! 105.000.-