Byl vydán Mozilla Firefox 156.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Vestavěný prohlížeč PDF se nyní spouští o 45 % rychleji. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 156 bude brzy k dispozici také na Flathubu a Snapcraftu.
Článek na Raspberry Pi představuje nový vzhled desktopu operačního systému Raspberry Pi OS v aktuálním vydání 2026-09-15.
Nové verze Roundcube Webmailu 1.6.19 a 1.7.4 řeší několik zranitelností.
Na Kickstarteru běží kampaň na podporu hloupého (jenom volání a SMS) tlačítkového DIY telefonu MAKERphone 2.0 od společnosti CircuitMess postaveného na ESP32-S3 a volitelně také s hodinkami MAKERband. S možností psaní vlastních aplikací. S volitelnými HW rozšiřujícími moduly.
Byla vydána nová verze 10.7 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyly balíčky HomeBox a Scrypted.
OpenRGB (GitLab) dospěl do verze 1.0 (YouTube). OpenRGB (dříve OpenAuraSDK) je svobodný multiplatformní software umožňující nastavení podsvícení celé řady různých „herních“ komponent a periferií.
Dnes startuje prodej headsetu Steam Frame. Počínaje dneškem se tedy můžete zapsat na seznam pro jeden z následujících modelů: Steam Frame 256 GB za 1 049 EUR a Steam Frame 1 TB za 1 279 EUR.
Vládní CERT upozorňuje na kritickou zranitelnost v GitLab Community Edition (CE) a Enterprise Edition (EE). Zranitelnost CVE-2026-85706 typu path traversal v Repository Commits API dosahuje skóre CVSS 10.0. Kvůli nedostatečnému omezení cest a chybějícímu vynucení autentizace může za určitých podmínek neautentizovaný útočník číst libovolné soubory ze serveru GitLab, a získat tak přístup k citlivým datům a konfiguraci instance.
Linux může běžet nativně na ESP32-S3 – bez emulace a rovnou s 9,7″ e-paperem.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 7.0.0. Pro sandboxing se na Linuxu nově používá Landlock místo Bubblewrap. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
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: