kokeilin tälläistä: label1=screen.point(x,y) mutta ei onnistunut. kuinka siis saan screeniltä halutusta x,y kohdasta point -käsky(llä)n väriarvon?
Declare Function GetPixel Lib "gdi32" (ByVal hdc As Long, ByVal x As Long, ByVal y As Long) As Long
Tolla onnistunee.
Dim Vari As Long Vari = Point(x, y)
Tuo on kai nopeampi.
https://www.ohjelmointiputka.net/koodivinkit/
jep, point on (kai) nopeampi ja ei tarvi laittaa api-funkkareita...
Point on vähän hitaampi, ja se lukee värin vain ohjelman omasta ikkunasta.
Antti Laaksonen kirjoitti:
Point on vähän hitaampi, ja se lukee värin vain ohjelman omasta ikkunasta.
Ooh! Miten API ei voi olla maailman hitain :o
Tiesin, että Point likee värin vain omasta ikkunasta, koska siitä puuttuu hDC-arvo, mutta en tiennyt, että se olisi myös hitaampi.
Laakkoselle vielä: API ei ole hitaampi verrattuna VBA:han, jos katsotaan funkkaria Polygon. VBA:ssa sinun pitää itse säveltää (tai säheltää) algoritmi, joka täyttää kulmikkaan esineen.
Niin no joo, pikselipiirto tehään C++:n makroilla kuten Metabolix (Huom oikeinkirjoitus) tuossa hienosti sanoikin joku aika sitten. Ellen tyystin käsittänyt väärin.
EDIT: VBA:han en ole koskenut (hyi kamala). Oletin sen olevan aika hidas, mutta eihän sitä ole nopeisiin urakoihin tarkoitettukaan. Se on tietääkseni tarkoitettu Laiskus Toimistorottus-lajin elämän helpoittamiseksi ;)
Yleissääntö on, että WinAPI-funktio on VB:n omaa nopeampi. :)
Ooh! En enää ikinä koodaa mitään nopeeta VB:llä. Siirryn C++:aan enkä koskaan enää palaa. Ja API on yleisesti hidas..? :D
kayttaja-4976 kirjoitti:
API on yleisesti hidas..? :D
Riippuu, mihin vertaa. DirectX:n verrattuna, joo, VB:n stardardikirjastoon, ei.
Kannattaa myös muistaa, että usein ohjelman hidas nopeus johtuukin ohjelmoijasta eikä ohjelmointikielestä.
Tämäkin on harvinaisen totta. Hitaudesta kannattaa aina ensimmäisenä epäillä itseään, ei käytettyä kirjastoa.
Ääh, innostuin TAAS kirjoittamaan pitkän viestin! Nöyyy!
Jos yhdellä API-kutsulla tekee paljon kerralla, se on nopeaa.
Jos usealla API-kutsulla tekee paljon, se on hidasta.
API:n hitaus VB:ssä johtuu siitä, että VB wrappaa monet API-kutsut "älykkäästi", mm. kaikki funktiot jotka käsittelevät tekstimuuttujia. GetPixel on poikkeus tässä, sitä VB kutsuu lähes niin nopeasti kuin mahdollista. Ongelma tässä onkin siinä, että GetPixel on äärimmäisen epäoptimaalinen tapa lukea ruutua, siinä missä SetPixel on vastaavasti epäoptimaalinen tapa piirtää. Kun miettii, niin API:a kutsuessa suoritutetaan paljon "ylimääräisiä" komentoja prosessorilla: täytyy valmistautua hyppyä varten muistissa, hypätä funktioon muuttujien kera, GetPixelin tapauksessa hakea pyydetyn device contextin bittikartta, valita sieltä koordinaattien mukainen sijainti eli selvittää kuvan leveys ja suorittaa kertolasku ja ynnätä siihen sijainti rivillä, jotta sitten voidaan vihdoin asettaa palautusarvo ja hypätä takaisin sinne minne pitää.
Enempää kuin paria pikseliä käsiteltäessä oikein pro-nörtti selvittäisi pointterin muistissa sijaitsevaan kuvaan ja feikkaisi long-muotoisen taulukkomuuttujan osoittamaan siihen. Sitä olisi jo todella nopeaa käsitellä VB:ssä, varsinkin kun kääntäisi ohjelman kaikki advanced optimization -vaihtoehdot päälle. Helpompia vaihtoehtoja edustavat BitBlt ja GetBitmapBits, jotka tosin luovat kopion ja ovat siksi (huomattavasti) hitaampia. GetDIBits on tietääkseni vähän nopeampi, mutta myös vaikeampi kuulemma käyttää.
Pääsääntö kuitenkin, että aina kun muistia tarvitsee siirrellä, niin se tietää hidastusta. Ja jos yrittää siirtää muistia tavu kerrallaan funktiokutsun kautta, niin se tarkoittaa äärimmäistä hidastusta. Ja jos kutsuu GetPixeliä VB:n Pointin kautta, niin lisää siihen soppaan mukaan vielä ylimääräisen skaalamuunnoksen X- ja Y-arvoille (tämä on se, mikä aiheuttaa Pointin hitauden GetPixeliin verrattaessa: kaksi Single-lukua muunnetaan kokonaisluvuiksi ScaleModen mukaan; ja sitten Point kutsuu GetPixeliä).
Aihe on jo aika vanha, joten et voi enää vastata siihen.