I'm interested in writing lots of HTML5 apps for devices with e-ink (bistable) screens.
But bistable screens exhibit a lot of strange and disconcerting visual artifacts whenever the screen contents change, especially when the browser is drawing and redrawing the layout when a page is loaded or when some javascript modifies the DOM.
So.... is there any way for my HTML code to tell the browser and its operating system to hold off on redrawing anything on the screen until it's done figuring out the new layout?
It is probably a dirty hack, but you could think of putting a full page opaque white div on the top layer - and then remove it with javascript once the page is fully loaded
Related
How can I make a clickable progress bar like this (image) ?
I want to choose one part of progress bar when I clicked on that part !
Many implementations of progress trackers, rely on images for their appearance. Using images obviously works, but it does present some problems.
Performance. When a web page includes images, the web browser has to make separate requests to the web server to retrieve those images. Those requests take time, and they can slow down the performance of the page.
Quality. Standard resolution images can look terrible on high resolution displays (such as Apple's Retina). There are techniques to adapt images to high resolution displays, but they take time, effort and programming to implement.
Fluid Layouts. Fluid layouts require that web content dynamically adapt to the width of the browser window. If the page includes images, it either has to scale the images (which can reduce their quality), crop the image (which modifies the content), or change the relative proportion of image content to text (which may undesirably change the page's look and feel).
Note: standard progress trackers probably aren't appropriate for fully responsive designs that must support small screen devices. If a task has enough steps to warrant a progress tracker, those steps probably aren't going to fit in a standard, horizontally oriented tracker on a small display.
Tracking progress reference
You can work using some input radio, :checked pseudoclass and sibling (~) selector.
You can take a look here: http://codepen.io/anon/pen/gpBExG
The trick is input[type='radio']:checked ~ .checker
It's an incomplete example but I've implemented main logic. You should create better UI using images.
I am working on an ePub3 and I created an interactive document that requires the full page to really look how it should. Unfortunately when I compile it with Readium to test the functionality in the ePub it shrinks it to one half of the viewport and leaves the other half empty (because it is, after all, a book).
I googled around and messed with the CSS and DOM and I cannot figure out how to remove that extra, unused page and make the one page with the interactive app take up the entire viewport.
Does anyone know if this is even possible? I know it might be pushing the standards of the ePub, but this app is a huge part of the ePub.
I appreciate any advice that can be given!
This is a reader-specific display function (not an ePub3 function), so you won't be able to control it. It is similar to what happens on most tablets if you turn them to read in landscape mode... The thing is, many readers don't read in this mode but some do, and you wouldn't want to take that ability to choose away from them.
If you are doing this in a reflowable book, I would suggest having the App be on it's own fixed layout XHTML page so that it is full-screen (on tablets) at least. You can do this by creating the new XHTML page and putting a link to it.
The best visual solution I can see in Readium isn't really a solution, but you should just go to "settings" and read in single page mode and possibly have a tooltip recommending that to readers when they get to the app.
Best of luck!
I've already read all the stuff around scrolling:
Structuring an HTML5 Canvas/JS Game
and so on:
HTML5 Canvas tutorial
The secret to silky smooth JavaScript animation
Google search "HTML5 Scrolling"
Canvas Games
Build a vertical scrolling shooter game with HTML5 canvas
Math mayem
CAAT JavaScript framework
(The latest one is impressive, but even though almost everything is done there's nothing about scrolling).
Here's what I'm thinking about, and I didn't found something valueable about that. An idea just came to my mind and I'm wondering if I should take a lot of time thinking about that and trying, or not (that's why I'm asking here actually).
I'm planning to do a game with a scrolling "à la" Mario.
The big drawback about scrolling is that you have to redraw the whole background.
I've already avoided two performance problems of the sprite / scroll: create two canvas one top of each other:
the background
the sprites
And just erase the sprites.
The problem is about the background: I'm making a full copy of the background to the "visible" canvas. (note: there's no problem about flickering because writing in JavaScript is a blocking operation and all modern browsers handle vertical synch, so no double buffering needed).
Here's an old version of what I'm writing, but you'll get the big picture:
Test HTML5
Now I'm wondering for the scrolling: what if I do a "background div" instead of a canvas, with the appropriate CSS (background image for the background), and write the tiles on the image directly, then change CSS to simulate the scrolling? Should it be faster? If so, why? Is there any good idea out there for this?
On a semi-modern+ computer with a semi-recent+ browser, the fastest thing to do is probably to take a super-long div with background images, set overflow to hidden and scroll by adjusting scrollLeft or scrollTop properties. This is MUCH faster than adjusting CSS properties as it shouldn't trigger any reflow calculation in the CSS engine. Basically, any time you touch a DOM property that could have CSS impact, the whole (or at least a lot of) of) the structure of the document needs to be re-checked and re-rendered.
You could load in chunks of the backgrounds as they get close to avoid the one giant massive image load. I don't believe there is any 100% surefire way to pull an image out of memory across browsers but removing references to it in the DOM or in your CSS probably doesn't hurt when you've scrolled far enough past a piece of your background. That way the browser's garbage collector at least has the option of clearing memory.
In pan-mobile solutions that rely on webviews (like Cordova/Phonegap), however, well that's why I arrived at this question.
I have no idea but I'm pretty sure mixing HTML and canvas is a lousy idea for performance purposes. Right now I've got a not-super-complicated android game choking on 50x50 100px tiles in a canvas element in an android web view that also has some basic HTML in the mix for stuff like controls and separating a couple other canvas elements from the rest. I basically have a birds-eye-view ship cruising around and doing scans with a cheesy radiating circle grahic that reveals elements on a map fog-of-war style. Works great in a browser. Complete disaster in the cordova app version.
I suspect the only way I'm going to realize my pan-mobile game dev dreams is to use one of the many openGL-wrapped-in-a-canvas-API solutions out there and completely ditch the HTML which I find damned convenient for UI implementation, given that the bulk of my experience is in web UI. Another general tip for web view HTML is to avoid scrolling within internal elements if you can (so just let the body handle overflow). Scrolling overflow in anything but the body didn't even work in Android 2's webviews and it still seemed to cause 4.1's views to choke on an earlier/simpler version of the app I'm working on.
My final conclusion: after many tries, including Eirk Reppen suggestion, I write directly "raw" into hidden parts of the canvas and use CSS: all webbrowsers handle already image flickering and all that stuff around, and they have already optimized everything.
So each time I've tried to "optimize", the results were worse.
It seems that webbrowsers are made to handle properly basic stuff made by beginnners... maybe because 99% of HTML content is made by beginners.
Here is a demo of scrolling an oversize canvas by changing the CSS margin, this one based on scrolling with time: https://jsfiddle.net/6othtm0c/
And this version with mouse dragging: https://jsfiddle.net/ax7n8944/
HTML:
<div id="canvasdiv" style="width: 500px; height: 250px; overflow: hidden">
<canvas id="canvas" width="10000px" height="250px"></canvas>
</div>
JS for the scroll-with-time version:
canvas = document.getElementById("canvas");
context = canvas.getContext('2d');
for (var i = 0; i < 1000; i++) {
context.beginPath();
context.arc(Math.random() * 10000, Math.random() * 250, 20.0, 0, 2 * Math.PI, false);
context.stroke();
}
var t0 = window.performance.now();
setInterval(function(){
canvas.style.marginLeft = -(window.performance.now() - t0)/5 + "px";
}, 5);
fastest scrolling is to scroll using CSS. So you draw all background once, not only visible part, but all, and hide that is not visible, and use css to scroll it (margin, or position). No redraw, only CSS changes. This work really fastest. But if all map is really huge, other custom ways can be better.
I scale an image down using css, but then its edges are jagged. However, if I quickly switch to another tab in chrome and then come back, it is drawn correctly. I assume that this is because of somethings that happens during redraw. Is there any way to force a redraw using jquery? I have tried adding classes, elements, and changing other attributes.
Ok, thanks to the bump, I will add my solution here. What is really happening is we are trying to force a repaint of the entire window. The following does the trick:
function reDraw(){
//hack to redraw the elements on the page to avoid choppy look of resized items
//prevent reDraw from firing too early
setTimeout(function(){$('body').hide().show(0)},66);
}
The show hide combination will force a repaint of the area affected. note that the 0 on show is needed. The 66ms delay is used because forcing a repaint immediately after applying styles (in this case, a css resize) will bypass the recalculate styles function in the browser. 66ms is aprox. 15fps so it should still appear to happen instantaneously on any screen running at 30fps (it will take two screen refreshes if all goes well). A small blip from pixelated to non-pixelated is visible on a 60fps display, but how many people pay that close attention anyway?
Anyway, that is our solution. For us, it was used on a website that is built very similar to a video game as far as animation loop and other things. Because the screen is being refreshed a lot already, we found we only needed to call the reDraw function after the resizing of a PNG, but your requirements may be different.
Note that this function can be very resource intensive, and I have observed that many browsers need to collect garbage after this so you may need to evaluate how necessary the realtime aspect is. Use sparingly.
Enjoy!
~techdude
Greetings Overflowers,
A result-set grid will be viewing snaps from HTML pages.
Snaps need to reserve original page layout including any tables, images...
Users will scroll through a snap to fully read a snapped page
Snaps can view varying-size windows anywhere in the HTML pages
Question: can lazy loading be implemented such that only viewed windows is loaded without losing the interactivity (e.g. hyperlinks) of snapped HTML pages ? If HTML pages cannot be tailored dynamically and lazy loaded this way, any interactive document format (e.g. PDF, Flash) is welcomed.
Update: Sorry for the confusion. Snaps are not images, they are random viewports anywhere from the HTML pages. In images it is simple, we can load only the portion we need to view. In HTML this is difficult, except when the portion is actually a whole viewable HTML tag element and it fits the needed portion. iframes would only facilitate the window to view the snaps onto, but I do not want to load the whole HTML pages because they are big, but only the needed snaps. The problem snaps can be somewhere in the middle of pages layout divisions where each division is very big. Therefore, fixing the layout size and lazy load their content later on alone would not help. I think layout transformations are necessary but very difficult. I wish I can take a picture of the full HTML pages and take whereever portion I need to view and this image portion keep interactive :)
Thanks !
You can use JavaScript with XMLHttpRequest (XHR) to fetch content asynchronously and place that text on the page (i.e. lazily loading content). I am not familiar with some of the terms that you are using (e.g. what a "snap" is), but if your layout specifies sizes (instead of relying on content, for example, to set the size of a table column), then this lazy loading can be done without re-rendering the layout.
As I interpret it - you have some fixed-size "viewport" div with scrollbars. You have Javascript that monitors the scrolling events of the viewport. You have to (somehow) have some rough idea of what content elements go where on the inner page. If a section is scrolled into view that has not been loaded, then send for it using AJAX. I think the trickiest part of this endeavour would be establishing the rough idea of what content elements go where without completely loading the content page, but perhaps you already have some assumptions you can make about the content.
Edit:
I do not want to load the whole HTML pages because they are big
This seems to indicate that you in fact do have some assumptions about the pages you're working with. How are the pages "big"? Do they have massive tables, massive images, a large number of images, flash content, javascript content...? You might have better success with loading all of the DOM that isn't of a certain tag type, and then selectively loading the rest.