Image not being drawn outside of viewport on Win8.1/Metro/IE on ARM.

[fake-name]

I have a Windows RT/Surface 2 tablet, and there are a number of odd behaviours when viewing a comic book on this device.

1. Pinch-Zooming in does not work - The page gets redrawn at the same relative size shortly after you release the pinch-zoom gesture. However, it looks like the pixel-pitch of the canvas is zoomed, so you can have a image that is the same size as when "fit to image", but only drawn using a few dozen pixels across.

Interestingly enough, if you then pinch-zoom-out, the image is not redrawn at the original pixel-pitch.

---

1. when you zoom using either the "+" button or the fit-to-width button, only the portion of the page that is within the viewport of the browser immediately after you press the button ever gets rendered. This means if you zoom in, and then scroll, everything outside of the newly zoomed viewport is blank.

   

I realise the MS Surface is not particularly common hardware, but I'm trying to figure out what's going on myself. I have been poking around, I changed document.body.style.overflowX = 'hidden'; in fitWindow and fitWidth to document.body.style.overflowX = 'auto';, but that didn't have any effect I can determine.

I'm not sure if this is a symptom of WinRT/ARM/IE11 doing something odd trying to not have to render the canvas outside of the viewport or what.

Frankly, I don't even know if WinRT/ARM has a console, let alone how to get to it. It's not easy to debug on, and everything works great on my desktop.

[fake-name]

Other comments - A "View Original Size" button is a very nice thing. I hacked one in by editing the built JS files, but I don't really understand the whole make toolchain thing, so I can't easily pull-request it back into the repo.

It's basically just

        ComicBook.prototype.originalSize = function () {
            options.zoomMode = 'originalSize';
            self.drawPage();
        };

and

            case 'originalSize':
                document.body.style.overflowX = 'auto';
                zoom_scale = 1;
                scale = zoom_scale;
                break;

[fake-name]

Ok, I can replicate the canvas not rendering outside the viewport issue using desktop IE11 on Windows 7. The issue is not ARM specific, but apparently true of all versions of IE 11.

I wish there were browser alternatives for the Surface, but the only browser you can run on ARM-based windows surfaces is IE.

[fake-name]

Arrrgh, so turning off GPU-assisted rendering in IE fixes the weird canvas issue. Fuck microsoft.

Or course, performance is also horrible with GPU assisted rendering off.

What the hell, microsoft?

[fake-name]

Ok, so the issue wound up being a problem with IE11 not drawing outside of certain limits on canvas elements, with the limits apparently varying depending on the platform's RAM.

In any event, I wound up writing a HTML5 canvas chunkifier (see here), that splits the raw image up into a set of canvas elements of limited size.

It's up at https://github.com/fake-name/HTML5-Comic-Book-Reader/tree/touch, but I don't know how useful it'll be, since I wound up removing a LOT of other functionality that I wasn't interested in along the way to clean up the parts I did. I completely removed the entire Pixtastic stuff, removed double-page display, etc...

It also now requires being passed a <div></div>, rather then a <canvas> element, since it then inserts the required number of canvas elements into that div.

[balaclark]

@fake-name Thanks for debugging this. I don't have access to a surface, but will take a look at this in a VM. Regarding the toolbar button, that is a good idea and I'll add it in.

[fake-name]

Yeah, sorry the bug report kind of wound up being a bit rambling. I opened the bug report when I first noticed the issue, and you're more or less seeing my troubleshooting process.

In any event, on desktop IE11 with lots of ram, I saw canvases that work out to many thousands of pixels. It's worth noting that MS specifies the max size of a canvas as 8192 x 8192 (in their docs).

In this case, I was dealing with some korean web-comics, which are often in a format where the entire comic is one enormously tall image (it's actually (somewhat) intended for mobile reading). If you imagine taking all 30+ pages of a common American comic, and stacking them vertically, you'd arrive at something similar.

[fake-name]

One other interesting issue is that the mobile detection mechanisms seem to fail to detect the Surface RT, so the menu is inaccessible altogether.

I solved that issue in my fork by just dropping the hover facility all-together, and adding another button-div in the middle of the page that opens & closes the top menu.