Jump to content
Search Community

skiller

Premium
  • Posts

    14
  • Joined

  • Last visited

About skiller

  • Birthday March 9

Profile Information

  • Location
    Wien

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

skiller's Achievements

  1. Hey there, thanks for the fix! Now at least it's behaving as before. The reason I resorted to using a matrix was that while in the project it seemed the only way that worked consistently across different browsers and OSes. You know, sometimes when you're bogged down in work, the deadline is approaching fast and you (as the last link in the food chain) have far too little time, you forfeit the elegant solution in favour of the one you know that works, and defer the elegant solution towards the phase when you actually have time to spend on exploration. Haven't we all been there? I can't really remember whether my problems with the suggested approach came from 3.12.3 (since noticed the newer version only later in the process), but in the meantime I figured I could alleviate some of the problems I ran into while animating clip masks with the common approach of using functions as parameter values, as suggested in the best practices and mentioned in the “common pitfalls” section of the GSAP website. I had the problem that I had to have a possibly resizing container in mind, and that using scalar values sort of froze the GSAP animation state calculated at the beginning of the page's lifetime – and something along the line of x: () => myValue alleviated that. But that is, as you know, a wholly different task and problem (but it might have irritated and destracted me and weakend my already insomnia-affected GSAP problem solving skills). So yes, the suggested solution is neat and nice, the bug in version 3.12.3 is gone in the next one, and I'm a happy camper! Thanks a bunch and best regards Constantin
  2. The problem with the project was that I had envisioned a slick animation of an object coming out of a space portal 😎(hence the animated clip mask) and sort of found a workaround/tweak/patch for the dented clip path rotation with 3.12.2. There was also a “swirl” graphic of the same dimensions layered on top of it, and since it was a nightmare to align well with the tweaked 3.12.2 clip path rotation and the havoc from the 3.12.3 version I ended up playing it safe and threw out the whole portal rotation.
  3. Sorry for the delay, but I finally got around to making two minimal examples: GSAP 3.12.2: https://codepen.io/ehrenstein/pen/rNPPGLy GSAP 3.12.3: https://codepen.io/ehrenstein/pen/qBggPXY The 3.12.2 version works okay, although the clip path rotation isn't around its center (= translation point given through the transformation matrix as .5,.5) as it should, the 3.12.3 version has the identical code, I just swapped out the GSAP version given in the JS settings. The clip path was designed to be within a 1 × 1 (unit-less) square so it can be used relative to the clipped object's dimensions (clipPathUnits="objectBoundingBox"). A transform translation of .5,.5 should thus always be understood as the clipped object's center. Best regards C.
  4. Just a quick note regarding the recent update to 3.12.3 (more details to follow later): Merely 17h before the project deadline all of a sudden animated clip paths (CSS+SVG) stopped working. Since GSAP was the only component that was updated recently, the latest update was a likely culprit, and reverting back to 3.12.2 resolved the issue. In short terms: I have an SVG path (normalized to a width of one and .5 units from the origin point), which I use as a clip path via matrix(1, 0, 0, 1, .5, .5). While GSAP was able to show a set matrix of matrix(0, 1, -1, 0, .5, .5) – a 90deg rotation –, it couldn't interpolate, so I ditched the rotation. I was able to have GSAP correctly interpolate a scaling Tween from (0.01, 0, 0, 0.01, .5, .5) with 3.12.2, but with 3.12.3 the clip mask suddenly flew in from the lower right corner. I'll post more details when the project is online, I just wanted to give a quick head-up so you can investigate in the meantime, if you like. Best regards C.
  5. Thanks a bunch – yeah, that's about it. I had built it up from scratch and got it working, but I'm definitely seeing a few elegant things here, especially concerning clamping and invalidating. Thanks for your help, y'all!
  6. Thanks for the hints! The reason I want to include touch as well is that I want the user on mobile to be able to swipe anywhere on the screen – swiping anywhere is supposed to be translated into horizontal values (you know, finding out which direction is the dominant one and mapping that value on the horizontal axis, or even combining the two with cos/sin whiz math and taking the travel distance as horizontal value). So there are similarities, but the differences are important. I'd scraped the internet for hints of how to do it and found a few comments à la “if you want to drag something, avoid the hassle and just use Draggable,” especially as hints at how to set up Observer for wheel, touch, scroll events as well as dragging are, well, a little sparse. So I understand that Draggable and Observer won't play along too well for now… or do you happen to be able point at hints about how to set it up so that a user can choose whether to touch or drag (or both) on mobile or to wheel or drag on desktop, respectively? Thanks a bunch in advance. Constantin
  7. Hey there, I'd like to move an element horizontally using wheel and/or drag on desktop and touch and/scroll on mobile. I've set up Draggable for easiest possible scrolling with inertia, and Observer for wheel events. I can sort of update a target value for the element to tween to, but the back-and-forth of the respective x values won't quite work. Any tips? Best regards Constantin
  8. Hey there, I'm developing a small, but media-heavy web application (a GSAP powered interactive game), and since I'm bound to tight restrictions regarding file size, I'm using Vite to 1.) write slick and modern module-based code (ESM, or ECMAScript Modules is the keyword here) and to 2.) tightly pack my code. Naturally, I want to provide GSAP as an external dependency (did I mention tight file size restrictions?), but I can't find an ESM-suited CDN link for GSAP and the Premium modules (how I'll be able to use these premium modules without exposing my personal license is a wholly different enchilada). Are there any? I have scoured the https://cdn.jsdelivr.net/npm/gsap@3.12.2/dist/ directory a little, but these all seem to be "normal" (i.e. require- instead of import-based) CommonJS libs. Thanks in advance C. P.S.: I can't provide a CodePen illustrating the problem because referring to GSAP works differently there (via the require syntax).
  9. Sorry for being a pain in the arse, but I'd like to suggest a few additions. While inspecting the code and the newly added cropping features, it turns out that I've already been down that road (which I don't mean in a diminishing way, your efforts are well appreciated!). It turned out, though, that there are a few requirements that still need to be met, especially that the crop selection must not exceed the image's bounds – something I found impossible to achieve without drilling holes into the TransformManager/TransformItem (which - per se - is okay and covered by the license, but it would still feel more natural as a TM/TI functionality). I assume the TransformManager's bounds are thought to restrict the movement of managed items within the limits of a "canvas", hence it merely accepts an unrotated rectangle relative to the TransformManager's space as bounds parameter. So what I have to do is monkey patch the TransformItem in a way that I can check if it is inside of the image bounds first before I allow it to move its handles – which results in a very undesired dependency and strong coupling between the TransformItem and the target object. How about enhancing the TransformManager in a way that it respects rotated retangles as well? Or even better: keep the current TransformManager "canvas" bounds and allow for TransformItems to have their own boundaries? That would make the TransformManager/TransformItem a black box again. So here's the desired enhancement/workflow: A TransformItem should accept an arbitrary UIComponent as a bounds parameter of its own, using its bounds and rotation to restrict its own and its handles' movement. So basically, I have a Flex component that is equivalent to the image's clip mask (undesired image portions are clipped through Flex's own clipping mechanism, i.e. clipAndEnableScrolling). When in crop mode, the image will stay in place, rotation is locked and scaling is forbidden. I have no problem with setting the component's image position back to its fixed position after it has been moved by the TransformManager/TransformItem – that's the easy part. The tricky part is restricting the item to the confines of the image, since the crop mask should never exceed the image (which it does with the TransformManager/TransformItem/Crop classes in their current form). Let me know what you think. Best regards Constantin
  10. Hi there, I had written an elaborate forum post about how I wished the cropping would work which I couldn't post because the forum wasn't reachable, but it turned out you did it anyway. Thanks again for your efforts. I just wanted to assure you that your efforts are very well valued, and the TransformManager is a great piece of code, and with the latest addition it has become even better. Best regards Constantin
  11. Thanks, great! You're a Wiz. A little different than I would've envisioned, but works like a charm. And to have this functionality *within* the TransformManager definitely reduces coupling. Best regards Constantin
  12. Thanks for the reply. The cropping should not be that hard, especially in Flex, where you can quite easily use Flex's own cropping mechanisms in its components (so there's no need to juggle masks like in an earlier approach I've tried). I'm basically switching from normal scale mode to width/height scale mode when the crop mode is activated because I don't want any scaling to occur (maybe I should try to simply lock scaling…), but I find it peculiarly hard to track and translate the right set of modifications, and when switching back to normal scale mode there are unwanted transform matrix modifications that ruin my calculations by occuring too early. But I suspect I still haven't grasped the intricacies of TM to their full extent. Initially, the TransformManager was suggested to make the scaling and cropping easy. Now I find myself sifting through the code, trying to grasp what happens when (and why), which calculations to stop and which modifications to allow. And, to be honest, the intensive use of generic objects doesn't make debugging easier. I'd rather have Value objects that I can subclass and put breakpoints into. Right now I've resorted to monkey patching the TransformManager, but is definitely not pretty. Maybe we can find a solution together, and if it suits the TransformManager well we could look for ways to blend that functionality into it. Looking forward to your suggestions… Best regards Constantin
  13. Hi there, I've spent a good part of the last few weeks trying to use the TransformManager for an application that not only scales, rotates, and moves images, but also crops them. I find the moving, rotating and scaling part compellingly easy to achieve with the TransformManager, but it doesn't seem to be suitable for moving, rotating and scaling cropmasks, too. The requirements: [*:2a6p5l9k] There is a layer with an arbitrary number of images and text elements (RichText) that are created on the fly by the user[*:2a6p5l9k] above that layer there's another layer that partially obscures the image/text layer (a kind of mask/template – but not a clip mask, since the parts "masked out" still "shine through" the mask)[*:2a6p5l9k] yet on top of that is a layer that contains control elements for the images/textitems that must not be obscured by the mask/template layer[*:2a6p5l9k] images are to be scaled, rotated, moved and cropped on the fly[*:2a6p5l9k] it should be possible to grab the items even if they're mostly obscured by the template/mask layer --> the handles and borders of selected items must appear "above" the template, even if the corresponding image is "below" the template/mask[*:2a6p5l9k] images must be scaleable/croppable in-place even if they're mostly "under" the template/mask The setup: [*:2a6p5l9k] The TransformManager sits atop the template layer and governs placeholder elements ("proxies"), which are created along with each text item/image and added to the TM[*:2a6p5l9k] the TransformItems relate to the transparent proxies, changes in dimensions, position, and scale are updated to the corresponding image/text (through Flex's commitProperties/invalidateDisplayList mechanisms)[*:2a6p5l9k] image items are their own clipmasks, i.e. masking and clipping is achieved through negative positioning of the image inside the image box element[*:2a6p5l9k] TransformManager operates in two modes: SCALE_NORMAL has image scale, move, and rotate as a whole, SCALE_WIDTH_AND_HEIGHT should keep the image in place, preserve/freeze the scaling, lock rotation, and only move the crop mask within the boundaries of the image The problems: [*:2a6p5l9k] TransformManager removes and adds TransformItems when switching their scale mode between scaling and cropping, resulting in the current item to be forced out of its ongoing modification[*:2a6p5l9k] the crop mask should be confined to the image, i.e. "scaling" and moving the image mask must not lead to a situation where part of the mask are outside of the image --> the TransformManagers bounding box remains unrotated, leading to undesired mask bleeding for rotated images and actually rendering the TM's bounds mechanism unusable[*:2a6p5l9k] TransformManager uses x/y + width/height as well as transform matrices to manipulate the TransformItems, making it very hard to simply "listen" to changes in the desired properties (sometimes dragging handles results only in a modified transform matrix, Matrix doesn't implement IEventDispatcher, though, leaving you with the only option to listen for frame events) The possible solutions: [*:2a6p5l9k]TransformManager should support bounding boxes that are not just unrotated rectangles, allowing for easy crop mask confinement inside of an image's area[*:2a6p5l9k]TransformManager/TransformItem should emit events when the transform matrix changes[*:2a6p5l9k]maybe even a full-fledged cropping mechanism out of the box? *wink wink wink* Thoughts are welcome, because I'm really stuck here. A colleague talked me into buying this pile of… monolithic code that I'm having a really hard time with. Hey, it costs three hundred bucks – I expect it to behave well then. Get me right, the TransformManager goes great lengths in the right direction, but it stops short. Or do you think it's not suitable for that purpose and I should get a refund? Best regards Constantin
×
×
  • Create New...