Seems when they load, all buttons are shown regardless of if the user is hovering over them or not. Then when hovering, they’re shown of course. Then moving the mouse away hides the buttons and it all works as normal. Seems unintended that it thinks the user is hovering onload when they’re not. Not sure why that’s happening.

(Also I don’t think it was happening until very recently. So possibly a breaking change.)

  • @wthit56OPEnglish
    1•3 months ago

    @[email protected] A minor bug to be sure, but thought it might be a very recent change that caused this, and may be a simple fix to sort it again.

    • @perchanceMEnglish
      1•3 months ago

      Is this still happening for you? I haven’t seen this problem

        • @perchanceMEnglish
          1•3 months ago

          Can you try again now? I wasn’t able to replicate it, but I did find another extremely strange issue that seems to be related to a recent windows update, where basically on (some?) windows machines the iframe wouldn’t update the rendering when the “processing…” was removed and replaced with the image, so it’d just be stuck on “processing” until you mouse over the iframe which for whatever reason triggers the rendering to update.

          So it’s possible your issue was related to that. If so (and either way, actually), thanks for reporting this! I was so confused about the reports/feedback saying that generation was so much slower recently, and I’m 90% sure this was the issue. Quite a relief.

          If your issue is still there, can you try running in guest mode if you aren’t already? I.e. click the avatar thing next to the three vertical dots menu, and click the guest option. I tried to replicate in Chrome 126, and Firefox on Ubuntu, and Chrome v126 on Windows 11 and Windows 10. Though I wasn’t able to test OS-level dark mode on BrowserStack, so if you could test light mode to see if the issue is gone, that would be good too.

          • @wthit56OPEnglish
            1•3 months ago

            Still happening for me. I’m using a Chromebook, so it’s using Chrome OS. So not a windows update thing.

            Something I did notice when stepping through the code was, there’s a canvas which is drawn to and then used to get a data url–which can be a little slow at least (though for smaller images like this should be fine). I’m not sure why it does this, as the api gives a data url for the image anyway. So there’s multiple copies of the same image in the device’s memory for every single image generation.

            (And many more for the referenceImage stuff, though I know no-one uses that.)

            I don’t know if any of that is related to the issue you’re seeing, or I’m seeing, but could be.

            • @perchanceMEnglish
              1•3 months ago

              Ah okay solved it, thanks! It was due to some sort of update which changed the result of a touch screen detection heuristic. I’m now using window.matchMedia("(pointer: coarse)").matches which seems to work correctly. So the buttons should only show up (without hover) for phones, ipads, chromebooks in tablet mode (not in trackpad mode), etc.

              as the api gives a data url for the image anyway

              Yeah it’s just a convenience trade-off - it’s sometimes handy to have the canvas already ready to go, since that’s the first step in manipulating the image. Should be extremely minor in terms of performance unless you’re drawing dozens of images per second (I’d guess that even a few dozen per second on a mid-range mobile device would be fine, but I could be wrong).

              • @wthit56OPEnglish
                1•3 months ago

                Oh interesting! Didn’t know that was a media query! 👍

                Are people manipulating AI-generated images a lot then? I don’t think I’ve seen any generators that do that, but I guess I’m new here. And also, the people creating such generators already know how to do that pretty easily, so probably won’t have any problem doing it themselves anyhow.

                The other concern is memory use though. Phones might be fine with the processing cost, but a lot of phones still have low graphics RAM (if any). One idea would be to generate that through a getter, and cache the resulting canvas. That way there’s zero performance or memory usage unless the generator actually uses it. (Which as I say could be a very small percentage of image generators, potentially.) And those that do use it won’t be any the wiser, it being lazily created when needed.

                Personally I thought converting to data urls is pretty slow. Maybe for images at this comparatively small size it’s less of an issue.