[IE] RAM memory bug?

[Verwijderd]

Zie de volgende pagina:

http://www.mobdb.com/got/memorybug/

Open je Task Manager van WinXP (ik weet niet of dit ook werkt met andere versies van Windows.) Drag je muis een paar keer over het plaatje. En zie hoe je geheugen enorm toeneemt.

Is dit een bekende bug? Is er een oplossing om dit tegen te gaan? In de body "ondrag=return false" zetten hielp niet in ieder geval.

(Sluit je browser process om je geheugen weer te clearen.)

[m33p]

Ik denk dat het iets van IE is want in FireFox heb ik er geen last van?

[André]

In Win2000 is er iig niets raars te zien in het geheugengebruik. Ik vermoed dat XP het plaatje op een verkeerde manier in zijn geheugen houd ofzo.

m33p schreef op 03 augustus 2004 @ 14:09:
Ik denk dat het iets van IE is want in FireFox heb ik er geen last van?

Topictitel: [IE] Ram memory bug?

[ Voor 43% gewijzigd door André op 03-08-2004 14:11 ]

[Verwijderd]

m33p schreef op 03 augustus 2004 @ 14:09:
Ik denk dat het iets van IE is want in FireFox heb ik er geen last van?

Vandaar ook de [IE] tag

[ Voor 77% gewijzigd door Verwijderd op 03-08-2004 14:10 ]

[roelio]

Lijkt alsof iedere keer dat je met je muis over het plaatje sleept, het plaatje een keer opnieuw in het geheugen gezet wordt (iederee keer stijgt mn IE6/XP mem usage met 4 a 5MB)

[Verwijderd]

Klopt, ja. Ik heb het inmiddels op kunnen lossen door er een zwarte <div> overheen te zetten met een alpha filter met een opacity van 0%, maar dit is natuurlijk gewoon een bug. Ik vond het alleen vreemd dat ik dit nog niet was tegengekomen in mijn 3+ jaar professioneel internet gebruik

[kamerplant]

IE5.0 @ Win2K: Klik + sleep en er wordt 3MB extra geheugen gebruikt, laat ik het weer los, komt dat geheugen weer vrij.
IE6 @ WinXP: Zelfde als bovenstaande, behalve dat het geheugen weer vrij komt.

Tsja..

[OkkE]

Hier op Windows 2000 met IE6 is het ook. Inderdaad erg raar..

[Verwijderd]

Heeft iemand Bill zijn e-mail adres? Heb al BillGates@Hotmail geprobeert maarja.. Ik ga het in ieder geval rapporteren. Ik zal vast niet de eerste zijn maar dit is toch wel een irritante "feature". ('t Is pas een bug als het is opgelost.)

[Verwijderd]

OkkE schreef op 03 augustus 2004 @ 14:21:
Hier op Windows 2000 met IE6 is het ook. Inderdaad erg raar..

Dan zal het wel een bug in IE6 zijn... ik heb het hier ook met WXP/IE6-SP1.

Maar waarom zou je dit op willen lossen in de source van je HTML?

Verwijderd schreef op 03 augustus 2004 @ 14:06:
Is dit een bekende bug? Is er een oplossing om dit tegen te gaan? In de body "ondrag=return false" zetten hielp niet in ieder geval.

Verwijderd schreef op 03 augustus 2004 @ 14:15:
Klopt, ja. Ik heb het inmiddels op kunnen lossen door er een zwarte <div> overheen te zetten met een alpha filter met een opacity van 0%, [...]

Het is tenslotte gewoon een bug van de browser, en nog niet eens een hele storende ook (getuige dat er nog bijna niemand over geklaagd heeft, dit is het eerste wat ik ervan hoor en IE6 is toch echt al een tijdje uit).
Het probleem komt in één specifieke browser voor, en als het goed is niet lang meer. Dus waarom er nog speciale (totaal niet functioneel kritieke) code aan vuilmaken?

[ Voor 76% gewijzigd door Verwijderd op 03-08-2004 15:50 ]

[Verwijderd]

Omdat het tooltje wat ik maak meerdere drag-acties verwacht van de gebruiker, welke meerdere keren enorm grote foto's gaat uploaden naar ons systeem. Zo'n 10 keer slepen voegt al snel 100 mb toe aan je geheugen.

Met 1 gig DDR heb ik na zo'n 10 foto's problemen mijn computer iets te laten doen.

Kun je je voorstellen hoe mijn klant deze uitleg vind?

"Ja, dan moet u even opnieuw inloggen in het systeem, maar dan wel in een nieuw browser proces zodat het gebruikte geheugen weer vrijkomt. Da's namelijk een bug, niet mijn fout, Microsoft weer. En nee, ik ga het niet oplossen, kan wel, maar da's geen mooie oplossing."

Dat is niet acceptabel, wat mij betreft. Dus moet er een oplossing voor komen. Natuurlijk komt die <div> "oplossing" niet over het plaatje te staan indien de persoon met Mozilla werkt. En nee, het is niet de beste oplossing ooit, maar het werkt.

Dit "for future reference".

[McVirusS]

Verwijderd schreef op 03 augustus 2004 @ 16:39:
Omdat het tooltje wat ik maak meerdere drag-acties verwacht van de gebruiker, welke meerdere keren enorm grote foto's gaat uploaden naar ons systeem. Zo'n 10 keer slepen voegt al snel 100 mb toe aan je geheugen.

Kan je iets meer over je toepassing vertellen zodat we misschien meerdere mogelijke oplossingen kunnen aandragen? Je kan zo'n plaatje ook neerzetten als background van een div; iets in de trand van:

code:

[nohtml]<div style="background: url(http://www.mobdb.com/got/memorybug/test.jpg) no-repeat; width: 1280px; height: 1024px;"></div>[/]

[Verwijderd]

Ook met SP2 op Xp doet het probleem zich idd voor (6.0.2900.2149), zo'n 3 mb per keer.

[Verwijderd]

Bug? Volgens mij zou het kunnen komen door die image toolbar die in IE 6 zit. Die heb ik expres uitgeschakeld omdat ik hem zo irritant vond (vertragend en onnodig).

[drm]

ReSistanZ:
Bug? Volgens mij zou het kunnen komen door die image toolbar die in IE 6 zit. Die heb ik expres uitgeschakeld omdat ik hem zo irritant vond (vertragend en onnodig).

Nope. Hier uit en hetzelfde probleem.

[Verwijderd]

McVirusS schreef op 03 augustus 2004 @ 16:45:
[...]


Kan je iets meer over je toepassing vertellen zodat we misschien meerdere mogelijke oplossingen kunnen aandragen? Je kan zo'n plaatje ook neerzetten als background van een div; iets in de trand van:

code:

[nohtml]<div style="background: url(http://www........4px;"></div>[/]

Het tooltje is nog in ontwikkeling, en ik had graag een voorbeeld gepost indien mijn werkgever dit ook op prijs zou stellen

Wat het in feite doet.. je maakt een selectie over een image waarbij de coördinaten worden opgeslagen. Redelijk simpel dus. Maar aangezien dit een drag actie verwacht over een vaste image... liep ik tegen een probleem aan.

Een achtergrond was ook een idee. Alleen is daar een kleine moeilijkheid mee... je kunt een background niet resizen. Als een klant een foto selecteerd die recht uit zijn digi-cam komt, moet de foto worden geresized naar een overzichtelijk formaat (softcoded resizen, gewoon een max breedte en hoogte van een x-aantal pixels in de img tag) zodat het selecteren makkelijker wordt.

De oplossing was dus, voor IE browsers, om er een DIV overheen te plaatsen die de preciese afmetingen heeft van het gerescalede (is dat een woord?) plaatje. Deze transparant maken had geen zin, daar had het IE team blijkbaar omheen geprogrammeerd. Een DIV met een filter alpha opacity van 0% (niet zichtbaar dus) werkte wèl, en maakte de boel ook niet verschikkelijk traag.

Een transparante GIF of PNG over het plaatje in kwestie bracht namelijk ook een memory probleem mee (drag je alsnog een image).

Dat was dus het probleem.
Vandaar deze oplossing.
Maar ik vind het erg slordig dat ik zo makkelijk een onwetende gebruiker zijn geheugen vol kan laten lopen.

offtopic:
je post maakt het topic nogal breed, een enkele linebreak om het geheel leesbaar te houden is misschien wel oke

[ Voor 7% gewijzigd door Verwijderd op 03-08-2004 23:27 ]

[Sir_Killalot]

Als ik um hier sleep opent tie gewoon de foto vanuit me cache in een nieuw venster, zal wel door MyIE2 komen

(WinXP SP1 + IE6)

[flashin]

Je zou voor dat probleem ook gewoon een flash oplossing kunnen gebruiken, alleen zijn er dan iets meer eisen voor de thuisgebruiker denk ik. (al valt dat tegenwoordig ook wel mee, ik ken weinig compu's zonder flash)

[crisp]

Verwijderd schreef op 03 augustus 2004 @ 14:06:
[...]
Is dit een bekende bug? Is er een oplossing om dit tegen te gaan? In de body "ondrag=return false" zetten hielp niet in ieder geval.

Ik heb ooit iets soortgelijks gemaakt waar het probleem niet optreedt: http://allcrispy.com/exp/croppainting.html
ik heb daar ondragstart en onselectstart="return false" in de body-tag staan