Zoom camera

[akaleth]

I'm using Pixi to create a graphing utility, and I want to be able to zoom in on parts of the data. Basically, click on part of the graph, a small window appears under the plot zooming in on a specific range of the plot. Primarily line graphs with lots of data points.

 

I remember reading somewhere (I believe it was on the github issue tracker) that "multiple cameras" are currently not supported because of the added overhead and complexity of maintaining multiple GL rendering contexts. So I'm figuring out the best way to go from there.

 

I've heard of the solution of making a second DOC containing all elements and then manipulate that separately (in this case, scaling up.) This seems to be a sound idea, but there is no native culling in Pixi, and this solution would involve culling parts of basic Graphics geometries - I don't even know where I would start on that (though it could be easier than I think.)

Another solution would be to do what's posted here: http://www.html5gamedevs.com/topic/6748-pixi-texture-to-image-object/ . Cache the stage as a bitmap and render it as a sprite, draw the sprite texture to the canvas and then make a dataUrl/image object to use with a library like Magnifier.js. It's a lot of hoops to jump through, so it seems inefficient, and I'm not sure if that would actually work since I'm not that familiar with Pixi, Magnifier and Javascript in general. Since multiple line graphs may be displayed on the same screen, this would also be better if I could specify specific sections of the stage to render to their own images for zooming. It's not necessary but it makes things easier.

 

For what it's worth, I'll likely be rendering the stage as a bitmap anyway to save time on rendering, since the graph will not be changing. Any potential inefficiencies in the second method could be overlooked, since this will not be happening every frame - only when the user clicks.

 

Could more experienced Pixi/JS users give me some insight on what's the best way to go?

[d13]

Maybe this?

Make a big, full-size DOC with all your stuff.

Scale it down to the size of your screen.

Make a copy of it with .generateTexture();

Scale that copy up to 1:1 original size. This is your magnified version.

Perhaps use a mask to create a magnifying glass effect.

 

You may not have to worry about culling if you're working with big bitmaps but you'd have to test that.

But, if you want to cull sprites that are not on-screen, just set their .visible properties to false.

Pixi is extremely fast, especially if you're using a SpriteBatch, so I wouldn't stress too much over premature optimization

 

There are many other ways you could do this too!

[akaleth]

Thanks for the input. I actually discovered masking after posting this but before it got approved, which definitely simplified things for me. I have a much better idea of where to go with this now.

 

When I mentioned culling, I was mostly referring to not drawing parts of objects that are outside of their DOC, but masks obviously solve that issue. Since there will only be lines and rectangles drawn in this utility, I don't think culling will be necessary for efficiency, but I'll cross that bridge if/when I get to it.

 

The original plan I came up with is:
1) Draw the graphs

2) Cache them as a bitmap

3) Make second DOC with that image scaled up

4) On click, make the second image visible, with a mask showing the correct range of values

 

The potential issues are:

- since it's being cached and not redrawn, the image would likely be blurry

- there are more data points being drawn than there are pixels on the x axis, so decimation would be necessary. the zoomed in image would need to show that extra definition

Both of those issues make the point of the zoomed in image moot.

 

To solve both of these problems, I could just redraw it larger+with more data when necessary, but your idea of drawing it larger and then scaling it down makes a lot more sense, and lets us decimate fewer data points. However, then there's another concern. I could have so much data to draw that the image has to be scaled down so far that the smaller image is too small to see - so decimation may still be necessary, even for the enlarged version. This might not end up being an issue on my side depending on how much data I end up working with, but assuming that Pixi doesn't do any magic when scaling images down, it is theoretically a shortcoming of this method. It's not that difficult to deal with, but it does need to be handled.

 

Any ideas on how to work around that? I suspect that I'll just need to deal with it, but I'm open to suggestions.

[d13]

> 2) Cache them as a bitmap

Unless I'm mistaken, you probably need generateTexture()

 

http://www.goodboydigital.com/pixi-1-5-2-webgl-canvas-renderer/

 

> - since it's being cached and not redrawn, the image would likely be blurry

It's a  1 to 1 snapshot, so I there shouldn't be any loss of the original.

 

Sounds like an interesting project, good luck!