Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Dobry den, delam program na prohlizeni obrazku. Na zacatku mi nasledujici metoda nacte vsechny obrazky. V seznamu imageNames jsou jmena vsech obrazku v urcite slozce.
private void loadImages() { mediaTracker = new MediaTracker(this); Toolkit toolkit = Toolkit.getDefaultToolkit(); for (String imageName : imageNames) images.add(toolkit.getImage(imageName)); for (int i = 0; i < 10; i++) mediaTracker.addImage(images.get(i), i); try { for (int i = 0; i<10; i++) mediaTracker.waitForID(i); } catch (InterruptedException ex) { ex.printStackTrace(); } }
Pres mediaTracker.addImage() a mediaTracker.waitForID() nactu a pridam pouze prvnich 10 obrazku - kdybych nacetl vsechny tak zbytecne zaplacam RAM a trvalo by to hoodne dlouho.
Potom mam metodu pro zobrazeni nasledujiciho obrazku po stisku sipky doprava:
private void drawNextImage() { if ((++imageIndex) == images.size()) imageIndex = 0; // ic je Canvas do ktereho obrazek vykresluji ic.drawLoadedImage(images.get(imageIndex)); ... mediaTracker.addImage(images.get(imageIndex+10), imageIndex+10); try { mediaTracker.waitForID(imageIndex+10); } catch (InterruptedException ex) { ex.printStackTrace(); } if ((imageIndex - 10) >= 0) mediaTracker.removeImage(images.get(imageIndex - 10), imageIndex - 10); }
V promenne imageIndex je index aktualniho zobrazeneho obrazku. V te metode si tedy pripravim nasledujici jeste nenacteny obrazek, tzn ten na indexu imageIndex+10 a zaroven ten o 10 mist dozadu (pokud je to mozne) odstranim. Mam tedy v pameti nacteno vzdy jen male mnozstvi obrazku, ne vsechny.
Program testuji v adresari, kde mam 65 fotek, zadna asi 2MB. Prvnich 10 fotek je uz prednactenych, takze se vzdy po stisku sipky doprava zobrazi velmi rychle, u 11. fotky je uz poznat rozdil a vzdy kolem 30. fotky dostanu toto:
Exception in thread "Image Fetcher 1" java.lang.OutOfMemoryError: Java heap space at java.awt.image.DataBufferInt. init (DataBufferInt.java:41) at java.awt.image.Raster.createPackedRaster(Raster.java:458) at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1015) at sun.awt.image.ImageRepresentation.createBufferedImage(ImageRepresentation.java:230) at sun.awt.image.ImageRepresentation.setPixels(ImageRepresentation.java:484) at sun.awt.image.ImageDecoder.setPixels(ImageDecoder.java:120) at sun.awt.image.JPEGImageDecoder.sendPixels(JPEGImageDecoder.java:97) at sun.awt.image.JPEGImageDecoder.readImage(Native Method) at sun.awt.image.JPEGImageDecoder.produceImage(JPEGImageDecoder.java:119) at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:246) at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:172) at sun.awt.image.ImageFetcher.run(ImageFetcher.java:136)
Pak mohu jeste dolistovat k cca 40. fotce - to dava smysl, protoze 10 fotek dopredu je prednactenych a pote se fotky uz vubec nezobrazuji. Pro jednoduchost jeste neresim to ze nacitam fotky z indexu, ktery uz neexistuje (je vetsi nebo roven images.size())
Proto otazka - jak mam tu pamet uvolnovat, abych predesel OutOfMemoryError?
No prave kvuli tomu, aby se dany objekt obrazku z MediaTrackeru odstranil volam toto:
mediaTracker.removeImage(image, index);
K cemu pak ta metoda slouzi? V tom kodu Shower.java jsem nenasel nic co by mi s timto pomohlo, mel jste tam na mysli neco konktretniho?
Ok, zkusil jsem tu hranici 10 snizit na 1, takze nacitam pouze jeden obrazek dopredu. Takto to zvladlo 37 fotek (predtim 30) a na 38 zase ta chyba.
Nechal jsem hranici stale na 1 jeda a program spustil s -Xmx1024m coz by melo programu poskytnout giga pameti, jestli jsem to dobre pochopil - takto to zvladlo 56 fotek, 57 hodila moji oblibenou chybu. Jak je prosim mozny, ze takovy programek na prohlizeni obrazku s predbufferovanim jednoho obrazku sezere 1GB RAM? Jedine prijatelne vysvetleni je asi to, ze ty nactanene obrazky stale zustavaji v pameti, co myslite?
Doted jsem automatickou spravu pameti v Jave bral jakou velkou vyhodu oproti treba C++, ale nyni mi pekne komplikuje zivot... Nejake navrhy?
images
nacitavas vsetky obrazky...
Tak jsem seznam objektu Image odstranil, obrazky nacitam az v pripade potreby podle seznamu imageNames a vypada to, ze to pomohlo. Ja ten problem porad daval za vinu MediaTrackeru a on az to mohl obycejny seznam objektu Image... zajimave.
Tookit.getImage()
a Image.flush()
.
Tiskni Sdílej: