Should I use workarounds for a bug in C3?

Ayy, currently not subbed to C3, I was subbed before, but stopped due to some concerns, but I wanted to sub again knowing C2 will not be supported and knowing bugs will be fixed and such in C3.

So I saw "Drawing Canvas" finally can rotate in a recent update, which made me think Drawing Canvas is now better than Paster from C2 since it has everything needed!

However, I quickly tested pasting a 9-patch object with an effect, and it is glitched. I made a bug report but it was closed and has been reported similarly before. No sign of the bug ever being fixed.

Bug report here: github.com/Scirra/Construct-3-bugs/issues/4202

So, Paster in C2 works perfectly and doesn't have this bug with pasting 9-patch objects, yet this bug with drawing canvas sounds like it may not be fixed due to the "complexity of the effects compositor".

I respect that it's a complicated engine, but Scirra are the programmers, Scirra created the "effects compositor" for their product, and therefore only Scirra can fix this bug... This confuses me, so what do I do now? Wait and hope? It is a very clear reproducible bug but I wasn't told "it will be considered in future" or "this will never be fixed"...

I reported the bug because its exactly what I needed for my project, I need 9patch objects to have effects and be pasted, and C3 is not able to do this and C2 CAN do this and I can't port my project over a bit more easily due to this (or even starting from scratch isn't easy).

So, my main question, if I start making a project that has a workaround with this bug, is that safe/recommended to do? The bug makes the "paste" result offset a bit weird so I could use adapt to this and get the desired effect I need, but I'm concerned that in the future, the drawing canvas will suddenly get updated, or effects compositor will be suddenly fixed and then my workarounds might become glitched and broken.

Ah I see, thanks for the info about the bug!

I have a few ideas for workarounds to test, maybe even using 2 drawing canvases to get what I need (keep one at 0,0 like you said, then use a second drawing canvas to position and paste on the first drawing canvas), but I was mostly worried about a sudden fix in future messing up whatever workaround I produced.

Ah yes that's almost a better alternative, but I do need to retain the alpha channel on the 9patch, which I think the snapshot doesn't do. Thanks for the idea!

It's cool, I'll try my workarounds out later, if any work then I'll probably subscribe again to make this project. Its mostly menus and 9patches in my project so I would have hoped it worked like paster did in c2.

I was mostly worried about logging in one day to see the compositor was fixed but breaks my entire project that relies on whatever workaround I used.

I decided not to bother trying to workaround the bug - I mean it works in C2 with paster and I have a licence already, rather than paying monthly/yearly for C3 to have to make my own workaround when it should just work as advertised (why not hide 9-patch objects from the "Paste Object" list? This will surely come up again with other people).

I purely wanted to subscribe to C3 for ease-of-use and not messing about with bugs or issues as often, and right away I've encountered a bug and I wasn't told whether it will be fixed or not, all I know is that "it's complicated"... yet it works in C2 perfectly.

My use-case for this was purely for performance gains - Being able to set an effect, paste it, then disable the effect, would give a performance boost in exchange for RAM usage (which is very minimal), especially when multiple 9-patches/sprites with different effect values are needed.

I hope Scirra reconsiders fixing the bug, or even making an internal "workaround" for bugged "Paste Object" instances, instead of leaving it up to the subscribers to fix.

why not hide 9-patch objects from the "Paste Object" list?

Sorry but I have to disagree with this. Your use case is very specific. The issue only applies to 9-patch objects and effects applied and with a canvas offset from the viewport. And you are only doing it because you don't want to apply the effects each frame to eek out extra performance in a project where most game objects are 9-patch. You would want to disable 9-patch object pasting entirely because of that, when it still works for the other 99% of use cases that other people have?

I haven't seen your project or any screenshots, so I can only guess that it is a GUI heavy project? Have you benchmarked the difference with just applying the effects? Because the effects you mention in your issue, black and white, HSL - they are the lightest effects for a GPU to run - the performance impact should be minimal.

Otherwise take the old school approach we used before shaders (effects) - pre-render the black and white, faded versions etc., and swap the object or just switch their visibility on/off.

simstratic

I meant specifically hiding 9-patch from the "Paste with Effect" option where the bug is present, although thinking more about it, locking down options would be a worse idea as it wouldn't allow any workaround to exist all, so I take that back!

Yes in my case, my project is GUI heavy and player-customisation heavy, I made the strong assumption that pasting onto a canvas would be much better for CPU/GPU rather than having many concurrent effects. I did not want to choose the baked-in approach, as this limits customisation, and limits colour choice to whatever I picked.

I am unsure how to measure this (Is it better to have a low-end device to test on?), I tried measuring on my PC but I get no difference at all in draw calls and such with the two approaches. I may be wrong about the performance gain, but as of now, I don't know, I still feel more inclined to move the load onto RAM in my mind, there's plenty more RAM compared to GPU power, especially on lower-end mobile devices.

Regardless, the bug exists and is reproducable, and it's unknown whether it will be fixed due to the complexity of the effects compositor.

it isn't just 9patch... sprites also are affected, and probably other types as well.

Drawing canvas would be great, especially for gui except the whole redraw on resolution change thing.

It's a deal breaker. There any many circumstances where you simply can't redo everything on the canvas.

And transfering to other objects is problematic.

So you got me curious and I did some testing today - and yeh - effects (HSL, B&W, probably others) seem to have a huge overhead on 9-Patches compared to sprites. Sprites I hit the CPU limit with lots of juice left in the GPU, but 9-Patches maxed out my GPU much sooner. I'm not sure why - every time I thought I had a theory, my testing didn't back it, so I'm afraid I'm no closer to unravelling the mysteries of the effects compositor for you.

I should mention this is Construct 3. I don't know if you see the same in Construct 2, so it might be worth checking? If you create a layout with 20 sprites with an effect, and another layout with 20 9-Patches with same effect, do you see a big difference in GPU% when running the layouts? (BTW you have to force a screen redraw - so give the sprites and 9-Patches sine behavior or something to make them move)

To answer your other question, when you can't test on a phone, a computer with integrated graphics will perform more similarly to a phone, they tend to have the same problems with fill rate, overdraw etc. Testing GPU% is tricky too, it can look really high when you first add a lot of objects/effects/etc., but leave it running for 5 minutes and it can drop significantly. I think when the GPU gets lots of new work it 'panics' and draws a lot of power to make sure the framerate doesn't drop, then it gradually winds down it's power until it is just maintaining the desired framerate.

Finally a word of caution about the RAM, yes there's more of it, but there's probably more background applications fighting over it, whereas the GPU should be almost fully dedicated to the game. Test on a phone while developing if you can - I tend to do a build when I'm heading to bed and test it in the morning - because performance can be very different.

So I realized today, I can test this in Construct 3 by with running the Construct 2 runtime, and with the C2 runtime I am definitely still seeing an increase in GPU% (both in the debug preview window and the Windows task manager). And this isn't a really low end GPU either (Radeon RX 570). In Construct 3, there's an option with the C2 runtime for WebGL, if I turn that off, then I don't get any GPU usage (but I get higher CPU usage as it's software rendering). This makes me think you're not using WebGL in your project?

I know which thread you're talking about (Chrome vs APK), and there was some fear mongering going on there. In the vast majority of cases, the performance should be very similar - there are these rare cases where it seems like WebGL is being disabled in the APK on a specific phone or GPU driver - the Chromium team is continuing to investigate. Honestly I wouldn't worry about it, but it's still good practice to test with an APK export occasionally.

The C3 runtime requires WebGL. The game won't run at all without it. You can still get software-rendered WebGL though, which can cause poor performance.