I was wondering if that would be doable to combine virtualization with animated filtering such as for instance what mixtitup provides: https://www.kunkalabs.com/mixitup/
The idea would be to present a lot of items (let say 30K images to represent), virtualize them and have the nice and smooth filtering animations of such library as mixitup.
Many thanks!
This type of animation (rearranging/reordering) isn't really supported by react-virtualized. I know people who do animated scroll-tos or animated reveals for new rows, and there are libs like clauderic/react-sortable-hoc that do animated drag-and-drop but the type of animation you linked to is a lot more involved.
You might be able to implement this by providing your own (stateful) cellRangeRenderer. Grid would manage windowing for you but you'd have to manage your own transitions. I've never tried it though.
If you do do something like that- I'd love to see it. Perhaps we could make a reusable component out of it.
Related
I've been trying to figure out the best way to show an existing CALayer in a secondary window to allow real-time full-screen output on a secondary monitor. Additionally I would like to have the ability to show real-time thumbnails in my application of the original CALayer, it seems like I should be able to find a setup that could fulfill both requirements.
So far my research resulted in the following options:
CALayer.render(in: CGContext) Using the original layer and redrawing it to additional views this way and setting up a timer or a CVDisplayLink to redraw it every frame.
Rendering the CALayer to a NSBitmap every frame. And using that bitmap in NSImageView across the application.
Using a CAMetalLayer and rendering the texture multiple times using a MTKView. I'm not really familiar with Metal, this seems like a fairly elegant solution, but I'm not sure if it is required to go all the way down to Metal myself.
Using a CARemoteLayerServer with a CARemoteLayerServer.
This seems like an overly complicated setup for in-process sharing of a CALayer and it feels like this approach is more suitable if I'd need to share the layer cross-process.
Using CAReplicatorLayer. Instead of using the replicator layer to create a grid of copies I tried to use it to create just one copy, but it seems like you cant add a CALayer to multiple "parent layers".
All in all I've found some workable solutions, but as I'm quite a novice working with Core Animation I'm not sure which direction is the least resource-heavy and I might still be missing an easier solution.
Has anyone tried something similar?
I am working on a desktop application with JavaFX. As seen in the image below, I have an open space for a sort of mascot character, which I hope to give simple animations to. They are simple enough that it would be possible--but incredibly hard--to make in JavaFX, but complex enough that I feel like I should use a different method. This is my first JavaFX program, so my experience level is pretty low. I am able and willing to make these animations in other software and create a gif or mp4, etc if necessary, but I'm just in the dark here. I couldn't find much documentation. Below, you can see the space I would like to fill with an animated mascot. What method would be the best for this level of animation?
A few days ago I've explored geomaps and, however, it turned out to be easy to change the properties of the elements.
But I have two questions:
I'd like to add rivers and forests on the maps. So Ive considered to set a background image instead of the geomaps figure. But I can't find a way to get this one fixed. Is there a way to set a background picture for a country or region?
How can I change the shape of the "bubbles" when you select a city e.g. "London"? I'd like to change it to a square.
Thanks in advance for your help!
Unfortunately what you're looking for is not available in geocharts in their current implementation.
Using a background image is possible in the sense that you can use CSS to make all shapes in the map transparent, and use a background image in the div to make it appear as if the little circles are being drawn on a map with forest and rivers, but you will run in to two big hurdles:
Your map will need to be identical in size/layout to the Google Maps SVG
If Google ever changes the SVG they use (or the view/projection they use) you will need to edit yours too
This isn't ideal, obviously. You could work around it by creating custom javascript to write rivers and forests on your map, but that is going to be a huge headache (especially if you are using multiple maps/views).
As for the circles, you can't change them to squares without hacking the actual SVG in the background with javascript. While this is definitely possible (if you're really good with SVG/Javascript), it again isn't using any of the fancy features of geocharts, and is more just a custom solution that will have to be updated if/when google updates their API.
Rather than doing it that way, you may want to look in to the same implementation on google maps itself. That will allow you to use custom markers, draw custom shapes, etc. with a lot more flexibility (and a much more stable API).
I'm in the concept phase of a Mac application that should let the user easily select and layout images for printing. It's a document-based app and a document can have multiple pages with lots of pictures in different sizes and rotations on it. The UI would kind of be like the UI of Pages.app.
Those pictures can possibly be large hi-res images. The user should also be able to print them in the best quality that the images offer.
I have re-watched some WWDC sessions about Quartz, 2D drawing optimization and NSView.
I know that there are a few different ways of accomplishing what I want to do, namely:
Use a custom view for a "page" and draw the images in drawRect: with Core Graphics/Quartz. Use CG transforms to rotate and scale images.
Also use a custom view for a "page", but use NSImageView-subviews to display the images. Use Core Animation and layer transforms to scale/rotate images.
What is the best practice for this? Drawing with Core Graphics or using NSViews? Why?
Thank you so much!
Johannes
Depends on how interactive these pages should be. If there is a lot of mouse interaction, e.g. dragging, selecting etc. I'd go with views. If you want fluid animations I'd even use plain CALayers with their content set to one image. This would also let you zPosition the images in case they overlap. A view based solution makes z-ordering hard.
The drawRect method should be fastest but you have hard times integrating user interaction and you must z-order manually.
This is a reply I got from opening one of my two Apple Technical Support Incidents:
Hi Johannes,
Thanks for contacting Apple DTS regarding your question about printing
and the different ways to construct your applications general UI (with
views).
There is a trend toward using layer-backed views in OS X (utilizing
Core Animation layers) which is motivated by the ability to easily
animate your application's user interface, with little work, when
needed. However in terms of printing, you would be better off to
implement drawRect for custom views so that the view contents can be
drawn at "full resolution" when rendered into the context for
printing.
If instead you use layer backed views at as those layers to
"renderInContext" the layer contents would be used to render, which
commonly will not be set to the full resolution of your source
documents/images. This is because layer backed views take additional
memory to store those bitmaps (cached layer contents), and because of
that, they are recommended to be sized appropriately for the screen
(which may not necessarily be sized appropriately for the printed
page).
Does this help guide your application architecture? Please let me
know.
So basically this means that using layer-backed views might result in sub-optimal printing quality. I've replied with some follow-up questions ("How setting wantsLayer = NO on the rootView right before printing help?") and will post the answers as soon as I get them.
All three approaches should work. Since you should be using scaled-down representations of large images anyway, I don't think there will be much difference. Do what you feel most comfortable doing.
My guess is just using layer-backed NSViews (one par draggable image) will probably work best for starters. If you find performance lacking, you can always micro-optimize. Note that you may have to make your views a tad larger than the images so you can draw the selection handles outside them.
This is all assuming that you will never want to do a more complex drawing.
I'm writing a video annotation application with Qt4 in which users need to be able to seek to various points in a video, putting markers on various objects and then setting keypoints for those markers so that they stay on the objects in the video as they move around. QGraphicsItemAnimation seems like a great place to start for these markers, however they need to be able to appear and disappear at specific times, which I can't figure out how to do with the QGraphicsItemAnimation. I could set the scale at 0 to make the objects disappear, but that seems like a pretty hacky solution, and I'm guessing that the paint engine would still waste cpu cycles trying to draw those invisible objects. Does anyone have a better solution than this? I'm using Qt 4.5.3 right now, but I'm willing to upgrade to 4.6 if it makes things easier. Thanks!!
It seems like the functionality you want of showing/hiding QGraphicsItem objects is beyond the scope of the simple "tweening" that the animation class performs. It is only for one object at a time, and any appearance or disappearance you have to write yourself.
You still might get some mileage out of QGraphicsItemAnimation (although the fact that it uses its own timer instead of being locked to the frame clock of your video is a little dodgy).
Neglecting "seeking" for a moment, there is a QTimeLine::finished() signal. If you let the end of an annotation's active animation timeline represent the point where you want it to disappear, you can trigger QGraphicsItem::hide() at that point. When it comes time to turn it back on, you would construct a new QGraphicsItemAnimation (based on the next run of keyframe data for that object) and call QGraphicsItem::show().
Note that one of the headlining features of Qt 4.6 is the QtAnimation framework, which is more sophisticated but also rather complex. I've not used it yet, but looking over the examples it seems like you might be able to "animate" a visibility or opacity property.