Closed TackerTacker closed 5 years ago
AshleyScirra
commented
5 years ago This is by design, and is similar to #3287. The default behavior of Drawing Canvas is to match the display resolution, but this changes when you change the layout scale. 'On resolution changed' is triggering in Drawing Canvas, but you're not redrawing anything in this trigger, so the default behavior is then to stretch the previous image content.
TackerTacker
commented
5 years ago What are the advantages of the current design, in which use cases is this beneficial for the user?
The solution for me right now should be to redraw everything every time 'On resolution changed' is triggering? Why would I even use the DrawingCanvas at this point if I need to keep the sprites that I paste around anyways to paste it basically every frame?
Maybe the design right now isn't the best solution and should be changed, or is the way the Paster plugin behaved no longer possible to achieve with C3?
AshleyScirra
commented
5 years ago It's designed so that if you draw content on Start of Layout, then resize the window larger and don't draw to the canvas again, it just scales the old content larger. The expectation is normally you'd redraw content in On resolution changed if you can, otherwise settle for stretching.
If it did what you seemed to expect it to, and could increase the resolution when you zoom in, that would mean all drawing canvases must always render at some much-higher resolution, using loads more memory, just in case you later decided to zoom in. That's really wasteful, and also technically complicated as sooner or later you hit the maximum texture size on the GPU. So you still couldn't render at higher resolution than that, and would still get quality loss when zooming in. So it would waste loads of memory and not even solve the stated problem. Therefore Drawing Canvas matches its drawing surface resolution to the display resolution - which changes when you zoom it.
TackerTacker
commented
5 years ago Okay i can see why it was done this way now, even though I don't agree with it. It is alright as a default behavior so that no one wastes memory by accident, but it shouldn't be the only option.
With the Paster plugin I did know exactly the memory impact it would have, because I could set the resolution independent from the size. Maybe a couple examples what I used Paster for which isn't possible feasible with DrawingCanvas anymore could help get my point across.
Arena game
I used it for an arena fighting game to paste blood onto the ground, I just needed one sprite in the project to paste all the blood once when an enemy died and then forget about it. I could calculate exactly how much memory it would cost me with your guid about memory usage and choose the size of the arena accordingly. I was also able to make the blood reflective and still hit my memory goals because i could set the resolution for the blood mask and the reflections much lower without it being really noticeable and the plan was to make the reflection quality a graphic setting in the end. 
Here is a link to a early alpha demo of that project on itch Demo
Now with the DarwingCanvas plugin pasted blood would have different resolutions dependent on how far zoomed in or out the game is at the moment of pasting it, or if you played it on itch.io and you played for a bit in the smaller iframe window and then switched to fullscreen, now all the blood pasted before is low res and blurry and you would need to past it all again or just clear the whole arena floor. I also couldn't set a lower resolution for effects like reflections to save memory and I couldn't reliably know how much memory it would cost me all. What if I zoom in past the resolution that matches the size of the DrawingCanvas, will the resolution get bigger and bigger the further I zoom in?
Worms like / destructible terrain games I made a worms prototype that uses the alpha for it's collision, so in this case the changing resolution would actually change the collision in the game Here is a link to that prototype on itch Worms prototype
I also used a similar method for a top-down version, in this I also lowered the resolution of the canvas to save memory and then smoothed it with fx
without smoothing
with smoothing
Here is a link to that top-down example on itch top-down example
There are more things that i don't have examples for right now but would also suffer from the same problems, like for example a drawing software that couldn't change the resolution of the canvas you are drawing on.
So basically for me the DrawingCanvas plugins auto-optimization right now feels unpredictable in visual quality and memory usage. It also lacks the option to optimize when I want it.
I hope you reconsider the design decision based on the examples provided and look into changing it even if it is technically more complicated.
TackerTacker
commented
5 years ago Will this be considered? Some reaction would be nice so I know someone saw the new comment.
AshleyScirra
commented
5 years ago This is a closed bug report. If you have feature suggestions please post them here: https://construct3.ideas.aha.io/
TackerTacker
commented
5 years ago This is a closed bug report.
Yes it was closed before I could even react to the "by design" comment. Also the by design reasoning seems really arbitrary for someone looking on this from the outside. Why is this issue by design, not a bug, and considered a feature request if I open an issue for it, but #3285 and #3288 are not?
If you have feature suggestions please post them here:
This is not a feature request, the pasting feature how it is right now does not work for a majority of use cases as I have demonstrated in detail in the comment above. Even just not clearing the canvas automatically when updated after a resize would be a start, then we wouldn't lose all the objects drawn on it, this would make it at least not break complete for players and just look ugly.
And besides that, I already posted a list with all this in the original suggestion 7 Month before it switched status to in development
Problem description
Using the DrawingCanvas plugin to paste and image into it while the layout is zoomed out causes the image to get blurry even though I never changed the size or resolution of the drawing canvas. This makes the drawing canvas pretty much useless for anything with zooming in it, especially because we have no control over it. I can only think of very few cases where this behavior would be desirable. The option to choose would be optimal ( see the gif in expected result ).
Attach a .c3p
drawing_canvas_bugs_02.zip
Steps to reproduce
Observed result
Blurry image after pasting it into the canvas in a zoomed out layout
Expected result
Sharp image after pasting it into the canvas in a zoomed out layout, best would be an option to set the resolution of the canvas manually like in the end of the gif
More details
Affected browsers/platforms:
Desktop r157 stable Chrome r163 beta
First affected release: ???
System details
View details
Platform information Browser: NW.js Browser version: 0.40.1 Browser engine: Chromium Browser architecture: 64-bit Context: nwjs Operating system: Windows Operating system version: 8.1 Operating system architecture: 64-bit Device type: desktop Device pixel ratio: 1 Logical CPU cores: 8 Approx. device memory: 8 GB User agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (@ac9418ba9c3bd7f6baaffa0b055dfe147e0f8364) NWjs/0.40.1 (like Chrome/76.0.3809.100) C3 release: r157 (stable) Language setting: en-US Local storage Storage quota (approx): 8388608 tb Storage usage (approx): 338 mb (0%) Persistant storage: Yes Browser support notes This list contains missing features that are not required, but could improve performance or user experience if supported. UI effects are disabled in settings. WebGL information Version string: WebGL 2.0 (OpenGL ES 3.0 Chromium) Numeric version: 2 Supports NPOT textures: yes Supports GPU profiling: yes Supports highp precision: yes Vendor: Google Inc. Renderer: ANGLE (NVIDIA GeForce GTX 760 Direct3D11 vs_5_0 ps_5_0) Major performance caveat: no Maximum texture size: 16384 Point size range: 1 to 1024 Extensions: EXT_color_buffer_float EXT_disjoint_timer_query_webgl2 EXT_float_blend EXT_texture_filter_anisotropic KHR_parallel_shader_compile OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context Audio information System sample rate: 44100 Hz Output channels: 8 Output interpretation: speakers Supported decode formats: Ogg Opus (audio/ogg; codecs=opus) WebM Opus (audio/webm; codecs=opus) Ogg Vorbis (audio/ogg; codecs=vorbis) WebM Vorbis (audio/webm; codecs=vorbis) MPEG-4 AAC (audio/mp4; codecs=mp4a.40.5) MP3 (audio/mpeg) FLAC (audio/flac) PCM WAV (audio/wav; codecs=1) Supported encode formats: WebM Opus (audio/webm; codecs=opus) Video information Supported decode formats: WebM VP9 (video/webm; codecs=vp9) WebM VP8 (video/webm; codecs=vp8) Ogg Theora (video/ogg; codecs=theora) H.264 (video/mp4; codecs=avc1.42E01E) Supported encode formats: WebM VP9 (video/webm; codecs=vp9) WebM VP8 (video/webm; codecs=vp8)