-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
extend framebuf.blit method with parameters to select a rectangle from the source #6365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
You could pre-allocate a bytearray big enough for the largest glyph on initialisation, then use uctypes.bytearray_at to create a reference to a bytearray of the correct size at runtime when you render the glyph. Or use a memoryview into the initial array. FWIW my writer class allocates at render-time: performance is OK rendering to monochrome devices but there is a problem rendering large volumes of text to color devices, which I think you will encounter. The blit method curently does not behave in a rational manner when blitting between framebufs with different color maps. Fixing this would enable blitting 1-bit glyphs onto multi-bit destinations. At the moment you have to do it in Python (as per my CWriter in the above module). See this issue. |
Thanks @peterhinch. Selecting some start byte index into the buffer doesn't solve that I need to select a bit (I'm only using 1 bit monochrome), nor that I only want to stamp X bits in width & height. Thanks for your library, I'll have a look. Incomplete, non-working code follows :
|
The angelcode executables appear to be Windows-only. My font-to-py utility is cross-platform between Windows, Linux and OSX. Many MicroPython users (self included) do not possess Windows machines. I am also concerned about the license: MicroPython and all my own libraries are MIT licensed. The key purpose of my library is specifically to convert fonts to bitmaps in Python sourcecode. This is crafted so that, when installed as frozen bytecode, it uses almost zero RAM. Glyph access times are short as they are lookups into a ROM-based table. For these reasons I see little opportunity for convergence between what we are trying to achieve. |
Yes, its Windows only, and I ran a VM to use it. I don't think its license really matters - it would only apply to the program, not the output. There are many other libraries and tools out there supporting the formats - text, xml and/or binary. |
I take your points about vector to bitmap conversion, bitmap editing, kerning and small bitmap sizes. My fonts are usable on small displays such as the 1.27" OLEDs in the photographs, which look a lot better in practice than in my pictures. However there is no doubt that hand-crafted fonts are best in tiny sizes. I considered supporting kerning, but avoided it because of the added code complexity. People run the Writer classes on ESP8266 and similar, where RAM is minimal. I will consider support for these formats, but I have a long "todo" list. I am more concerned about a solution to the color blitting problem which is a major headache for rendering large quantities of small text. I could fix this, but as a change to the C code it would require a special firmware build which is something I'm not keen to support. My offer of a PR was not taken up. |
Uh oh!
There was an error while loading. Please reload this page.
I am trying to implement font rendering. I have loaded a single bitmap of all letters, and now I want to blit each letter to the destination. However, there is currently no framebuf method for blitting a partial framebuf.
Currently its blit(fbuf, x, y, [key])
I suggest blit(fbuf, x, y, [key], [sx,sy,sw,sh]) although I'm not clear on whether width & height are better than right and bottom.
It would bring major performance gains to do partial blitting in C over Python, and I don't want to allocate a tiny framebuf for every letter of the alphabet.
The text was updated successfully, but these errors were encountered: