I'm currently creating an interactive anatomy app for learning purposes.
I'm starting with a spine module, which contains 24 vertebrae, a pelvis, skull and spinal cord.
Each piece is a separate transparent image of the same size, and each are layered top to bottom.
This works and looks great! The problem is, it is extremely processor intensive. Adding and removing little pieces, zooming in, almost any interaction at all is VERY slow.
Is there a way to layer all of those images in a performant manner? I would like for a student to be able to remove a lamina, and have that vertebrae swap out the image. Or to zoom in on only the Lumbar vertebrae and interact there.
What approach, technology, etc should I be looking at?
https://jsfiddle.net/whetw8o5/1/
Fiddle for reference.
Fiddle contains a transition tag for height, so you can easily use a tool and modify the height of the parent #spineo tag and see how much trouble it has.
Fiddle performs better than my site because it is by itself.
Related
I'm trying to build myself a very simple framework to manage drawing content to the same webgl canvas via multiple views and react. I want to able to use the same resource in different areas of the window, so i'm trying to avoid using multiple canvases.
The end result should be something like this example from three.js.
I'm pretty confused with how to manage this from the html side and am struggling to figure out if any limitations of this approach should be considered.
<WebGLContext.Provider value={contextState}>
<canvas ref={canvasRef} style={canvasStyle} />
{children}
</WebGLContext.Provider>
This is my top level wrapper. With this, i can instantiate a <WebGLView/> wherever and get the rectangle to be used as the "viewport" into the canvas. Just like in the example i scissor out that rect and draw some content there. Because my entire react app renders on top of this, i can put any content over that view. But... i can also obscure it. This only works if divs above it are transparent, or there is hardly any overlap between these viewports.
The view is something like:
<div ref={viewRef}>
{children}
</div>
Another approach that i had in mind is to use react portals to manage another layer, above the canvas.
Something like this:
<WebGLContext.Provider value={contextState}>
{children}
<canvas ref={canvasRef} style={canvasStyle} />
<div ref={aboveCanvasPortal}/>
</WebGLContext.Provider>
Since i know the rectangle of the viewport for my webgl drawing, i can manage the html above it in a similar way, draw an absolutely positioned div in it, and put some UI content in there. This also doesn't feel like it would scale very well, but i could at least have a scrollable column with a background color, a webgl view in it, and some ui on top of it. Overlapping components would probably crash this.
The view is something like:
<div ref={viewRef}>
{ReactDOM.createPortal(children, aboveWebgl)
</div>
I've been thinking of using toDataURL() and then passing it as an image background to the views. This seems like it would solve the stacking/overlapping issue, and i could have a very simple html structure. But this is also a tremendous amount of overhead to add to webgl? If so, is there a way to do it cheaper, since the browser has to compose all of this somehow anyway?
Use case wise, my main use case is to use it with something like react-mosaic, where i just have a bunch of rectangles, very flat within one viewport, a div or the window. The second approach feels like it would work best. And then perhaps if i put a modal on top of that, creating another layer of below,canvas,above, html, would make sense, but like no more than that?
When taking a deeper look into the code of the three.js example you have provided, you will note, that there's just a simple <canvas id="c"></canvas> without any wrapping at all.
The key to your question is not to think primarily about viewports, but about Scissor Boxes -- as used in the aforementioned example in its function render(). If you prefer (like me) to use raw WebGL instead of three.js, take a look at the MDN Doc on WebGLRenderingContext.scissor() and on basic scissoring as a starting point.
That should reduce the complexity of your problem and return it back to the level of (a more performant) WebGL, instead of trying to patchwork on HTML level.
I am currently working on a project that involves a background image that needs to be linked specifically to an element within a container div.
The link is: http://idearevolution.ca/clients/jab/
The challenge I am running into is that as I resize my screen the green circle doesn't stay behind the guy. I've run into issues with responsive background images having to work with elements within a contained area in the past, but I've never been happy with my solutions.
The last thing I tried was using Sass to run a loop, adding a media query to update the position every 10 - 20 pixels. I don't like this solution however because of the code bloat it generates.
I am wondering if anyone has run into this issue before and if so, how do you go about resolving it? I've tried a few things but I'm just not happy with any of the solutions.
Any help would be great.
Thanks,
Andrew
Semantics would fix this problem best.
The semantics of using an image is this:
If the Image does not add to the content and explanation of the site,
do not use the image.
So, in truth, this image looks like it should only be part of the design.
Therefore, use the CSS3 Feature of Multiple Backgrounds.
Bit of background
I've been producing a Flash-driven webcomic for three years now, incorporating some basic animation, a synced soundtrack and zoom-drag page viewing. The recent Flash-bashing, my desire to reach iHandhelds and my preference for open versus proprietary means that I want to make the move to HTML5 techniques this year. In the long-term, I think the writing's on the wall for Adobe's product, and I'm not entirely convinced that's a bad thing.
I'm relatively comfortably with both CSS and HTML, having worked a little in web design before. However, JavaScript is a foreign country to me, and I simply wanted to get some advice as to
whether what I want to achieve can be accomplished consistently across all browsers and
what the best techniques/approaches to the problem would be.
Any advice, even general principles, are very welcome. I've already sought out several HTML5 tutorials and introductions, which lead me to believe that the canvas element will be foundational to my plan; however while all the individual problems I face have been answered by many blogposts and guides, combining the various solutions into a single entity is something I'm not currently able to figure out, as I'm not certain of the limitations of the new HTML5 tags, or of best practice.
If I'm successful in achieving what I'm after, I'm going to post the full code online with an explanation of all the elements. Webcomics might not be a huge domain, but having a resource that did this would have made my life a lot easier - hopefully it'll help someone else in a similar position.
What I'm after
Here's a diagram giving the basics of the design requirements. I'll explain the elements, and the desired extras, below.
(Perhaps the simplest way to demonstrate what I'm after would be for interested folks head over to my website and see how my comic currently works. This isn't a plug - it would simply give the quickest insight.)
At core, I'm after a viewer that will:
display text (SVG image) in a canvas element above an raster image the page's panel art
both images should be zoom-and-draggable in sync but should ideally fade in separately, with the raster image coming first, followed by the SVG image
I'm guessing that the best way to accomplish this would be to layer two canvas elements one above the other using z-index, with the SVG file in the uppermost element. These could then be nested, as in the diagram, within a div element that would carry the zoom-drag function. Is this a reasonable approach, or are there more efficient options?
The next and previous buttons are self-explanatory. Would it best to have each page (bearing in mind some will involve animation and music) on a separate page, or to have all pages within a chapter on a single page, with the buttons making them visible progressively? I imagine this would have a great impact on loading speeds.
Finally, I'd like to have the viewer capable of displaying fullscreen if the reader desires. I imagine this could be accomplished by using Javascript to make the canvas elements and their surrounding div switch between different CSS giving a px-defined size and 100% height and width. Is this a good approach? Is it possible to apply the size change to the div element only and have the canvas elements automatically follow suit, possibly by defining their size via % in CSS?
Desired extras
At various points in the comic I make use of basic animation techniques - simple movements of layered raster images across the viewing pane. This would be simple to accomplish, I imagine, using Javascript; am I correct in thinking that applying overflow:hidden to the wrapping div will prevent images larger than the viewing area from spilling outside the viewer area?
I also want to synchronise audio with some of these animations. I understand that synchronising canvas events with the audio would be the best way to do this on, permitting both to begin activity only upon page loading or next button click.
That's about everything. As said, any advice at whatever level would be greatly appreciated, even if it's 'yes' or 'no' to the various questions I've asked. At root, it would also be good to know if HTML5 is the best option for what I'm after or whether (with gritted teeth) I should stick to Flash for now and go after handhelds using Adobe AIR.
As a front-end developer, I've been given a mock-up design to implement. This design features several tachograph-style icons, which have me stumped as to the best way to mark them up in HTML and CSS.
The images look like the following:
Obviously these assets represent the empty state and the full state respectively.
My issue is this: how can I mark-up these images so that I can show varying levels of completion, i.e. 10% full, 60% full etc?
Waiting in anticipation to hear your answers.
I would seriously recommend looking into the Raphael javascript library. You can knock something like this up in just a few lines of code.
See also this question: Drawing a half gauge/speedometer (JavaScript Canvas or Java Swing Example needed) where I gave an answer including a four-line code sample using Raphael, which provides an animated fuel gauge. You'll need to tweak it for your design, but even then it's only going to be a few lines of code.
The great thing about using Raphael to draw things like this is that it is fully compatible with older browsers, even IE (as far back as IE6 if you need it), without you having to do any special code to support it. It's a great little library.
Hope that helps.
Given that the image reprisents actual data and isn't purely a design mechanism, I'd mark the image up as an HTML image.
<img ... alt="10%">
If your concern is about showing portions of the image, one way you could do this would be to set the image as a background to some container and use width and height to identify the amount of the image to show.
i'm not an expert on html5 /css3, but would you not use the html5 arc command to create a mask to reveal the full state.
As you have a 270 degree rotation from empty to full, you'd just map the value as percentage of 270 to create the value of the arc that would mask the appropriate value.
I believe that there is a java script Math.PI that might help to.
The designer I'm working with has given me a monster of an implementation issue...
Page background is grey, and atop of it is a crumpled paper texture (non-repeating with painted design elements) for the first 600 pixels (by 1400 pixels across; currently centered as a non-repeating background). At the bottom is another div with more text on it -- with a dropshadow, complex line pattern for the background and ripped edges, hovered slightly above the top div.
Saving the top part as a JPG and the bottom part as a transparent PNG leads to filesizes of +1mb.
Saving the top part as a JPG and the bottom part as a JPG doesn't work very well due to the drop shadow. It would technically work to save the bottom part as a slice with elements of the top part underneath the dropshadow, but it would have to line up pixel-perfect always or else look crappy. And at that point, I might as well save the whole site as one big image...
If the bottom part had a solid colour for the background, I could set each edge to have a different transparent PNG. However, the line pattern on the bottom part means that this wouldn't work.
My question is ultimately:
How the heck do people do ripped edges these days without making their site one big image?
Thanks!
Screengrab:
CSS3 does provide a border-image property, which should be able to help you with the ripped border effect (although even then, it would help if it was a repeating image).
See here for the W3 specification.
However it may not be much use to you, because browser support for this feature isn't great -- IE doesn't support it at all (not even IE9), and while most other browsers do support it, they all currently have gaps in their support and require a vendor prefix in the CSS property.
See CanIUse.com for a full browser support table for it.
To be honest, I think you should just go back to your designer and ask him to make it easier to work with -- he's probably just created something he thinks looks good, but is unaware of the limitations of the design he's put together; if you explain the issue to him, he may well be able to produce something a bit more usable for you.
There's really not a whole lot you can do here.
Page edges are ideally seamlessly repeated via repeat-y, and in your case it looks like the texture is one big image. You're either going to have to settle for sub-par performance or present the designer with your issues.
Check the archive of this blog for a good example.
You either have to fix the background images and use the entire image (or the top image AND the bottom image) and make the background non-scrolling. OR you have to get him to design a pattern that can repeat and then use a smaller PNG.
Clearly, your designer has a print background....
Ok, there's ways that will most likely theoretically work. But theoretical isn't always practical. I suspect your desire is to have cross-browser capability, as all of us should. So, start by throwing most new CSS3 tricks out, thanks to legacy IE. Forget box-shadow, forget crazy png tranparencies without hacks, etc.
What you're left with is doing a gigantic .jpg background. That will load....eventually.....
In this case, you can see the storm on the horizon, so run for cover. Go back to the designer, explain why this is about as smart an idea as texture layered over gradients, and help them understand why our buddies at Microsoft have made this virtually impossible. Just like a fully-flashed out site, it can be done somehow....but it's probably not the best use of time and resources. The web isn't print, it's dynamic...and when you put something "on a page" it's not going to stay put as it would in Illustrator, nor can you guarantee that your user is going it experience it in 100# glossy with a metallic overlay. Yes, I was a designer before I was a developer.....
Sound like a cop-out? Maybe it is. But I've been in your shoes, building sites for credit cards. My team was forced to waste thousands of dollars of the bank's money trying to make sites work with designs that probably shouldn't have been done on the web, thanks to print designers doing double-duty, getting designs approved prior to talking to the tech team....after, of course, we presented management with the options. Ultimately, it got the boss fired for going over budget.
although this is untypical, I would recommend cutting a big square shaped hole in the center of the image so that you're only left with the edges themselves and a transparent center and saving to PNG. Then saving the center part itself as a jpeg and putting the jpeg directly on top of the PNG in the correct position.
This way, the majority of the very large PNG will contain very little data and be a very small file size. The rest of the data would then, obviously, be jpeg and therefore smaller.