Byly vyhlášeny výsledky (YouTube) 28. ročníku D.I.C.E. (Design, Innovate, Communicate, Entertain) Awards: Hrou roku 2024 je Astro Bot.
Všem na AbcLinuxu vše nejlepší k Valentýnu aneb Dni lásky ke svobodnému softwaru (I love Free Software Day, Mastodon, 𝕏).
Vývojáři openSUSE Tumbleweed oznámili, že u nových instalací se ve výchozím stavu přechází z AppArmor na SELinux. Uživatelé, kteří chtějí zůstat na AppArmor si mohou AppArmor vybrat v instalátoru.
Hector "marcan" Martin skončil jako vedoucí projektu Asahi Linux aneb Linux na Apple Siliconu. Projekt ale pokračuje dál.
PostgreSQL byl vydán ve verzích 17.3, 16.7, 15.11, 14.16 a 13.19. Řešena je zranitelnost CVE-2025-1094 s CVSS 8.1 a více než 70 chyb.
Dnes je Světový den rádia. Použili jste někdy GNU Radio?
Před 33 lety, ve čtvrtek 13. února 1992, se tehdejší Česká a Slovenská Federativní Republika oficiálně (a slavnostně) připojila k Internetu.
Byla vydána nová verze 9.10 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Český LibreOffice tým vydává překlad příručky LibreOffice Math 24.8. Math je modul editoru vzorců v kancelářském balíku LibreOffice a poskytuje možnosti rozvržení pro zobrazení matematických, chemických, elektrických nebo vědeckých vzorců ve standardní písemné notaci. Příručka je ke stažení na stránce dokumentace.
Společnost Backblaze zveřejnila statistiky spolehlivosti pevných disků používaných ve svých datových centrech za rok 2024. Ke konci roku 2024 vlastnila 305 180 pevných disků. Průměrná AFR (Annualized Failure Rate), tj. pravděpodobnost, že disk během roku selže, byla 1,57 %. V roce 2023 to bylo 1,70 %. V roce 2022 to bylo 1,37 %.
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: