Split rendered image into smaller pieces using a <table> element?

[danielnez1]

Hello,

I have been trying WRP to load pages on the browsers supplied with the newer versions of PC/GEOS (Webmagik on Breadbox Ensemble and Skipper on Newdeal Office 3.2a). These environments can run into out of memory and speed issues when loading large images (I suspect this is due to them being DOS based real mode GUI environments relying on paging to access memory beyond the 640k barrier).

With that in mind, i have been experimenting with splitting up the rendered image of a website into smaller pieces on a static HTML file using a table, with each chunk being placed inside a

element. based on my anecdotal observations, it does seem to render the image elements quicker compared to rendering a single image, however would such an approach break the image map approach WRP uses to track mouse clicks (I am not too familiar with how they work)?

Cheers,

Dan

[tenox7]

Ha! That's a neat idea. I think you don't even need a table you could potentially just add images beside each other in a row and <BR> for a new row. As for breaking image maps, you could just have a separate map for each image.

[rhaleblian]

Going further, if we think of WRP as VNC, but just inside a browser, then you could think about parts of an image canvas (the rendered page) being damaged and needing a redraw, like VNC and X11 do.

You'd cut the image into the regions that might need to change independently. The regions won't be the same size; they might be like an octree. Assuming the vintage browser can only request a whole page at a time (no fetching pieces async), you still send the whole page but make sure the client can still hit its cache for unchanged imagemaps. Then, with luck the client only needs to download the changed piece.

@danielnez1 did you have something working? I could try it on NEXTSTEP.

[tenox7]

Right I can see that working. You could (perhaps) control cache of individual images/slices and basically expire images you want to update and download for the changed ones. I think some experimentation is in order.

[rhaleblian]

(perhaps) control cache of individual images/slices

This is where the idea might just overreach -- a 90s browser may only get a timestamp for a page resource, and nothing for any resources it references, like IMG tags. But if that were the case that would imply that old-school browser could never cache images, which seems unlikely?

[tenox7]

I believe even in the 90s browsers still used HEAD (even in HTTP/1.0 https://datatracker.ietf.org/doc/html/rfc1945#section-8.2) to check if resource (image in this case) has been modified since last request. Of course browsers vary a lot and testing is required, but theoretically the idea is solid. I will probably write a test tool that will output a grid of small images that will be constantly changing and we can get it tested on all different browsers.

[rhaleblian]

Wrapping with <TABLE> should keep browsers from line breaking image rows, i theenk that any whitespace or tag boundary is otherwise fair game for a renderer to insert a newline...

[tenox7]

I think nbsp was always there, but table without CSS could never be fully controlled. I'm not sure if border=0 cellpadding=0 cellspacing=0 will work as you think it will. Maybe...

[danielnez1]

@rhaleblian Sorry for the late reply, no I never got around to implementing it :-(

As others have pointed out, I discovered my rudimentary experiments (I never got as far as hacking the Go code) showed that the different browsers handle the visual formatting of <table>, <tr> and <td> elements slightly differently, so cause whitespace issues.

[tenox7]

Right! Before CSS there was no way to control this and different browsers handled this differently.

There are other options I'm exploring in the mean time.

GIF encoding can be speed up dramatically by using concurrency. Perhaps heavier compression, less colors could be used by default, especially for less graphical pages. GIF image download could start earlier on the client and be blocked or even made progressive as it's being encoded.

[rhaleblian]

Good research! Such were the days. Yes to small palettes. It keeps with the retro aspect of many use cases. On the NeXT there's only four colors and they are all monochrome! With dithering magic.