Memory leak bij updaten van <img>

[WeeJeWel]

Hoi,

Ik heb een probleem en kom er niet uit. Google noch IRC biedt geen antwoorden.

Stel, ik heb een <img> die elke seconde een nieuwe afbeelding (src) krijgt via JavaScript. Dit werkt prima, maar het blijft dat de browser (Chrome in dit geval) de oude afbeelding in het geheugen houdt. Dit is natuurlijk niet de bedoeling want die is niet meer zichtbaar en hoeft dat ook niet meer te worden.

Kan ik op een of andere manier de image vrijmaken en daarna de nieuwe afbeelding laden? Zoals ik het nu heb crasht de website (intern) elk uur. Niet praktisch

Alvast bedankt!

[ieperlingetje]

Helpt het als je een parameter eraan hangt? Iets van plaatje.jpg?0123456 . Dan weet de browser dat het een ander plaatje is en hij niet in het geheugen hoeft te bewaren, anders kun je de bug nog altijd melden op http://www.chromium.org/for-testers/bug-reporting-guidelines

[Freeaqingme]

Wat je wellicht kan doen is eerst een nieuw img element aanmaken (en het plaatje erin laden), en wanneer dat klaar is het oude img element verwijderen en het nieuwe element ervoor in de plaats ervan in de DOM te zetten.

[Croga]

Wellicht een optie om het anders te doen?

- Webserver het plaatje laten vervangen, serverside. Naam van het plaajte blijft hetzelfde, plaatje wordt anders.
- Javascript eens in de zoveel tijd het plaatje herladen in plaats van ander plaatje te laden.

[WeeJeWel]

ieperlingetje schreef op zaterdag 30 april 2011 @ 16:08:
Helpt het als je een parameter eraan hangt? Iets van plaatje.jpg?0123456 . Dan weet de browser dat het een ander plaatje is en hij niet in het geheugen hoeft te bewaren, anders kun je de bug nog altijd melden op http://www.chromium.org/for-testers/bug-reporting-guidelines

Gebeurt al

Freeaqingme schreef op zaterdag 30 april 2011 @ 16:11:
Wat je wellicht kan doen is eerst een nieuw img element aanmaken (en het plaatje erin laden), en wanneer dat klaar is het oude img element verwijderen en het nieuwe element ervoor in de plaats ervan in de DOM te zetten.

Net geprobeerd, het geheugen gebruik steeg ongeveer 5x zo snel

Croga schreef op zaterdag 30 april 2011 @ 16:11:
Wellicht een optie om het anders te doen?

- Webserver het plaatje laten vervangen, serverside. Naam van het plaajte blijft hetzelfde, plaatje wordt anders.
- Javascript eens in de zoveel tijd het plaatje herladen in plaats van ander plaatje te laden.

Gebeurt al

[ieperlingetje]

Dan lijkt het me eerder een browser bug en denk ik dat je er zelf niet zoveel kan aan doen.

[MueR]

Op canvas gaan tekenen? Maar een heel andere vraag. Waarom wil je uberhaupt elke seconde een plaatje wisselen?

[ieperlingetje]

Plaatje zal waarschijnlijk afkomstig zijn van een webcam stream.

[Croga]

WeeJeWel schreef op zaterdag 30 april 2011 @ 16:22:
[...]

Gebeurt al


[...]

Gebeurt al

errr.... die twee opties zijn mutually exclusive.... óf het is dezelfde filenaam óf het heeft een toevoeging..... Daarnaast schrijf je in de OP ook dat de bestandsnaam verandert.... dus óf jij begrijpt mijn uitleg niet óf één van je omschrijvingen is niet geheel duidelijk.

[WeeJeWel]

Croga schreef op zaterdag 30 april 2011 @ 16:30:
[...]


errr.... die twee opties zijn mutually exclusive.... óf het is dezelfde filenaam óf het heeft een toevoeging..... Daarnaast schrijf je in de OP ook dat de bestandsnaam verandert.... dus óf jij begrijpt mijn uitleg niet óf één van je omschrijvingen is niet geheel duidelijk.

Nouja de webserver vervangt het plaatje. Ik moet alleen forcen om te refreshen door een andere bestandsnaam op te geven (?random=123).

Wat overigens, soort van, werkt is de oplossing van Freeaqingme. Het geheugen komt vol tot ca. 250MB en dan wordt 'ie weer geleegd. Niet heel netjes but hey, it works.

Canvas is inderdaad ook een goede optie, zal het eens proberen.

[Jaap-Jan]

WeeJeWel schreef op zaterdag 30 april 2011 @ 16:38:
[...]

Nouja de webserver vervangt het plaatje. Ik moet alleen forcen om te refreshen door een andere bestandsnaam op te geven (?random=123).

Wat overigens, soort van, werkt is de oplossing van Freeaqingme. Het geheugen komt vol tot ca. 250MB en dan wordt 'ie weer geleegd. Niet heel netjes but hey, it works.

Canvas is inderdaad ook een goede optie, zal het eens proberen.

En heb je dan wel geprobeerd om zonder ?random=123 te doen en server-side een random plaatje te kiezen, zoals Croga voorstelde? De bestandsnaam veranderd dan niet en misschien zorgt het ervoor dat de oude data wordt gewist en er geen geheugenlek is. En anders kan het nuttige informatie zijn voor de Chrome- developers.

[ Voor 16% gewijzigd door Jaap-Jan op 30-04-2011 16:43 ]

[NMe]

WeeJeWel schreef op zaterdag 30 april 2011 @ 16:38:
[...]

Nouja de webserver vervangt het plaatje. Ik moet alleen forcen om te refreshen door een andere bestandsnaam op te geven (?random=123).

Door dat te doen heeft die oplossing van Croga geen enkele zin meer. Zorg liever dat die image niet gecached kan worden met de juiste cache headers en hanteer dezelfde url zonder toevoeging voor de refresh.

[WeeJeWel]

Als ik random=123 niet meegeef wordt gewoon de oude afbeelding weergegeven.

Deze headers worden verstuurd:

code:

Server  Dorgem/2.1.0
Date    Sat, 30 Apr 2011 14:56:43 GMT
Content-Type    image/jpeg
Content-Length  84184
Last-Modified   Sat, 30 Apr 2011 14:56:43 GMT
Cache-Control   no-cache, private, must-revalidate
Pragma  no-cache
Expires 0

[MueR]

Je expires header is ongeldig, dus die wordt genegeerd.

[EricBruggema]

als het om webcam plaatjes/beelden gaat kun je het plaatje ook een parameter van de tijd meegeven! dat doe ik namelijk voor al mijn ajax gerelateerde aanroepen script.php?t=(timestamp) en werkt perfect!

[frickY]

Toon het plaatje in een <iframe> in plaats van <img> ?

[NMe]

EricBruggema schreef op zondag 01 mei 2011 @ 06:43:
als het om webcam plaatjes/beelden gaat kun je het plaatje ook een parameter van de tijd meegeven! dat doe ik namelijk voor al mijn ajax gerelateerde aanroepen script.php?t=(timestamp) en werkt perfect!

...

Dat gaat precies tegen de andere adviezen in dit topic in en veroorzaakt alsnog die memory leak.

[_Thanatos_]

Is het wel een memory leak? Je mag toch verwachten dat een moderne browser dit niet meer heeft. En zo wel: bugreport maken.

Ik denk dat je een memory leak verwart met de geheugencache. Een laagje dat browsers bovenop de disk cache hebben, om sneller naar een eerder bezochte pagina in de sessie te springen.

[RobIII]

_Thanatos_ schreef op zondag 01 mei 2011 @ 19:21:
Is het wel een memory leak? Je mag toch verwachten dat een moderne browser dit niet meer heeft. En zo wel: bugreport maken.

Ik denk dat je een memory leak verwart met de geheugencache. Een laagje dat browsers bovenop de disk cache hebben, om sneller naar een eerder bezochte pagina in de sessie te springen.

^ Dat vermoed ik ook eerder. Het is niet erg als je geheugen (of andere resources) gebruikt wordt: daar is 't voor. Op 't moment dat 't echter niet meer vrijgegeven wordt wanneer er behoefte aan is dan zou je misschien eens kunnen gaan denken aan een bug.

[Voutloos]

Volgens de topicstart draait het uiteindelijk uit op een crash. Alhoewel het geen kwaad kan als ts duidelijker beschrijft wat de 'crash' in houdt.

[WeeJeWel]

Voutloos schreef op zondag 01 mei 2011 @ 22:32:
Volgens de topicstart draait het uiteindelijk uit op een crash. Alhoewel het geen kwaad kan als ts duidelijker beschrijft wat de 'crash' in houdt.

[wackmaniac]

Ik denk dat je het slimst de oplossing van frickY kan gebruiken; dat werkt ook zonder javascript en de afbeelding zal niet in de memory cache blijven hangen. En het is lekker makkelijk natuurlijk

[RobIII]

Voutloos schreef op zondag 01 mei 2011 @ 22:32:
Volgens de topicstart draait het uiteindelijk uit op een crash. Alhoewel het geen kwaad kan als ts duidelijker beschrijft wat de 'crash' in houdt.

Ik krijg het hier iig niet gereproduceerd; vandaar dat ik "crash" wat breed interpreteerde

[YopY]

Ik zou het toch bij Chrome / Chromium neerleggen als bug of issue - vzviw doe je geen gekke dingen, en moet het wijzigen van de src van een image geen overflow van het een of ander tengevolge hebben.

[RobIII]

YopY schreef op maandag 02 mei 2011 @ 16:42:
Ik zou het toch bij Chrome / Chromium neerleggen als bug of issue - vzviw doe je geen gekke dingen, en moet het wijzigen van de src van een image geen overflow van het een of ander tengevolge hebben.

Je zult dan iig met een helluvalot meer info en een reproduceerbare testcase moeten komen willen ze je serieus (of überhaupt in behandeling) nemen. En datzelfde zou ik in dit topic ook graag zien; anders blijft het gissen.

[WeeJeWel]

iframe oplossing lijkt te werken tot nu toe

[BtM909]

Kan je een hele simpele testcase online zetten... Ik heb een beetje het gevoel dat je heer en meester bent in 't vaag doen

[RobIII]

BtM909 schreef op dinsdag 03 mei 2011 @ 10:51:
Kan je een hele simpele testcase online zetten... Ik heb een beetje het gevoel dat je heer en meester bent in 't vaag doen

^ Precies

Ik heb inmiddels een eigen testcase online gezet en kan 't probleem niet reproduceren.

Graag had ik, om te beginnen, het volgende gezien:
* Een voorbeeld image (of gelijkwaardig; dus qua afmetingen, bestandstype, compressie e.d.)
* De daadwerkelijk (relevante dus!) HTML/JS in kwestie
* De http-response van de server