optimised rendering for large areas
See original GitHub issueUsing breseham
for drawing every shape is extremely convenient, but the visual noise is significant. It might be better to render continuous, large surfaces with a background color, e.g. using chalk
.
the borders of the area would look different however, so this would require some further investigation.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:4
- Comments:18 (9 by maintainers)
Top Results From Across the Web
3D Rendering and How to Optimize Your Approach for ...
The easiest trick on our list is that adjusting the render region size is one of the most effective ways to significantly save...
Read more >How to Render Faster - In-Depth Guide to ... - CGDirector
Optimize your Render-Settings: Limit Ray-Bounces, Set Cut-off Thresholds, Utilize Adaptive Sampling, Clamp ray intensity, Reduce your AOVs, Use faster GI- ...
Read more >Optimize Largest Contentful Paint - web.dev
Optimize Largest Contentful Paint. A step-by-step guide on how to break down LCP and identify key areas to improve.
Read more >GPU rendering optimization guide - XESKTOP
In this article, we aim to cover ways that could help artists meet deadlines, save cost while rendering using GPU rental service &...
Read more >3ds Max | Autodesk Knowledge Network
How to optimize workflow, enhance program performance and improve scene stability when working with very large (1+ ... Long rendering times.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thank you for all your wonderful high quality input @verdy-p !
Based on it, i just started to work on a mapping logic for the currently 2x4 sized, bit operation based BrailleBuffer. It will map all possible characters to the most-pixel-overlaying ▀ ▄ █ ▌▐ ▓ ■ ▬ equivalent and will allow an easy implementation without touching too many other parts of the current logic. Let’s see how that goes and how we can continue from there 😉
The next logical step would indeed be the automatic terminal type detection and giving the user the choice to switch during runtime.
Thanks again!
Yes but not within Windows (even with Ubuntu Bash, which still uses the Windows console even it it is using Unicode, i.e. codepage 65001=UTF-8) with its supported fonts (I gave a basic list) that must be monospaced, otherwise they are not selectable in the terminal. This means that all characters in the font must have the same metrics. May be there are other suitable fonts that may be installable on Windows to support more symbols. But the list of block characters supported are working on all platforms (Windows/Linux/MacOS/Android) because they are part of widely used legacy charsets, and because the terminal fonts for Windows have served as a minimum base subset to support in many other fonts. It would be interesting to develop an opensource monospace font (mapped with Unicode) for extending bitmap image emulations: it would be installable on Windows, Linux, Unix, MacOS. I gave the name of the high quality font from the Google Noto font set. I could have also named the monospaced font made by Michael Everson (wellknown member of Unicode) that supports many symbols as well: I’ve not checked if they would support more block graphics.
2017-05-12 19:54 GMT+02:00 Jannis Redmann notifications@github.com: