Nem tetszik az a logika, ahogyan a nyáktervezője a track-et próbálja húzni, nem tetszik az, hogy réz felületek nem generálódnak automatikusan újra, miután leteszek egy track-et, így bőszen nyomogatnom kell a "B" betűt.
Ami viszont végképp kiborító, hogy a kurzor, egy szálkereszt mozgatása olyan szinten megetette a Xorggal és compizzal a futásidőt, hogy a zenehallgatás ropgni kezdett a gépen. Tehát csak a kurzor mozgatása, nem egy megfogott objektumé. Ugyanakkor a PCB 3D modelljének forgatása, valós idejű renderelése kevesebb futásidőt vitt el, akkor nem akadozott a hang, mint egy sima szálkereszt kirajzolása. Gyanítom, kimaradt egy zárt ciklusból valami nanosleep()-szerű hívás.
- locsemege blogja
- A hozzászóláshoz be kell jelentkezni
- 173 megtekintés
Hozzászólások
Eléggé aktívan fejlesztik -> reportold!
Nekem is felemásak az érzelmeim a KiCad irányába egyébként.
- A hozzászóláshoz be kell jelentkezni
A grafikus felület várakoztatása nem a program, hanem az alatta lévő grafikus library feladata, ami itt a Xorg.
Xorgnál a következő felállások szoktak lenni (tudtommal):
- Meghívják az XNextEvent() függvényt, ami ha nincs esemény, alvásba küldi a szálat a következő eseményig.
- Az XNextEvent()-et csak akkor hívják meg, ha van a queue-ben esemény, amit az XPending() függvénnyel ellenőriznek, ami viszont azonnal visszatér a queue-ben lévő események számával, ami ha nulla, akkor a program XNextEvent() helyett várakozik, de nem feltétlenül sleep segítségével.
Namármost, ez a micsoda a wxWidgets 3-at használja GUI-ra, ami tud más GUI widgetsetekre (GTK 1-2, Qt4, stb.) wrappelni, vagy natívan X11-el működni. Azt hiszem, wrapping esetében feltételezhetjük, hogy az említett widgetsetekben le van rendesen kezelve a dolog.
Ha a másik esetet nézzük, a wxWidgets X11-es library-jében megtalálod az evtloop.cpp fájlban a wxGUIEventLoop::Dispatch() függvényt. Amint látod, itt a kettes felállás van: XPending() == 0 esetén vagy ráhúz egy timeoutos select()-et az X11-es descriptorokra, vagy, ha Nano-X-szel volt forgatva a lib, akkor meghívja a GrGetNextEventTimeout() függvényt, ami pedig megint csak egy timeoutos select()-el várakozik. (https://raw.githubusercontent.com/ghaerr/microwindows/master/src/nanox/client.c)
Egyszóval nem maradt ki semmilyen sleep innen sem.
Namármost, a kurzor mozgatása maga is egy XEvent, tehát ha folyamatosan mozgatod a kurzort, akkor mind a select(), mind az XNextEvent() folyamatosan visszatéreget és ekkor a szál visszakapja a futást, azaz lehet rajzolni. Viszont, ha nincs mit rajzolni, akkor hiába kapja vissza, gyakorlatilag azonnal küldi is vissza pendingbe az egészet, márpedig te nem tudod akkora sebességgel mozgatni a kurzort, hogy két kurzormozgatás generálta XEvent között ne legyen legalább pár milliszekundum differencia, ergo nem tudsz "sleepless" állapotot felállítani.
Ha viszont túl sok mindent kéne rajzolni, akkor tovább tarthat a kirajzolás, mint amennyi idő a folyamatosan mozgatott kurzor okozta XEvent-ek között eltelt, ennek megfelelően az XEvent-ek fel fognak torlódni a queue-ben, ami viszont ténylegesen perzisztens azonnali visszatérést fog eredményezni az eseményfigyelő függvényeknél, ergo így felállhat a "sleepless" állapot.
Ez így persze nem biztos, csak feltételezés, logika és némi tapasztalat alapján, de szerintem nem az időzítéssel van baj, hanem annyi mindent akar rajzolni kurzormozgatáskor (valószínűleg feleslegesen), hogy bedugítja az event queue-t.
- A hozzászóláshoz be kell jelentkezni
Köszönöm. Képes voltál utánanézni, vagy használtad többször a wxWidgets-et? Egyébként hardware függő ez. Picike notebook-omon ugyan nagyobb a futásidőigény, mint nyugalomban, de közben folyamatosan megy a zene, pedig az egy pici N4200 CPU-val szerelt gép. A nagyobbik gépen a CPU sokkal izmosabb, de nagyon régi a VGA-kártya, amit nouveau driver hajt. Ez a ropogás itt jött elő.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Utánanéztem. A wxWidgetset konkrétan sosem használtam, de az X11-et sokat programoztam és amit leírtál gyanús volt, úgyhogy letöltöttem a forrásokat és belekukkantottam. Persze, hogy hwfüggő: ha egy sleep hiányozna, minden gépen visítanának a ventilátorok, az viszont a hardware függvénye, hogy mi számít "túl sok rajzolnivalónak".
- A hozzászóláshoz be kell jelentkezni