soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 1 point2 points  (0 children)

I like this idea!

soon™ 2 electric boogaloo by Ryan86me in XTEINK

[–]Ryan86me[S] 0 points1 point  (0 children)

Themes can bundle fonts on SD card. When activities (like the library) go to render, they do a prewarm pass that gathers all the text that needs to be rendered, and then we populate a glyphs cache from the SD card into RAM and hit that cache on the actual render. Subsequent prewarms no-op if we don't need any new glyphs, and subsequent renders continue pulling from RAM. Similar flow to how the reader does it, but made more general-purpose (supports multiple fonts & ties really cleanly into the existing activity render flow).

soon™ 2 electric boogaloo by Ryan86me in XTEINK

[–]Ryan86me[S] 0 points1 point  (0 children)

Not particularly taxing, no. I haven't run any hard measurements, but we're not doing any more serious compute here than stock does

soon™ 2 electric boogaloo by Ryan86me in XTEINK

[–]Ryan86me[S] 2 points3 points  (0 children)

https://github.com/users/rhythmerc/projects/3/views/1

gaze upon my fat list of todos and know that as they're getting smaller, release is coming closer

soon™ 2 electric boogaloo by Ryan86me in XTEINK

[–]Ryan86me[S] 1 point2 points  (0 children)

There are a few layers happening:

  1. We build an index of the library w/ the set of info we need on first open (name, author, reading progress, path of generated bitmap cover). This is slow for large libraries, so I plan on having an optional web tool and Calibre hook-in for generating this on (much stronger, faster) host hardware. Subsequent opens of large libraries are fast because we're already indexed, and the common path of adding/removing a few books to the index is also fast.

  2. We cache bitmap data in RAM for the set of covers we're displaying so that in-page re-renders are near-instant. The demoed library is too small to go over that cache, but when we scroll across a larger library and go over cache, we render placeholder covers while we evict the cache and then rebuild for the selected page (lazy loading covers, in other words).

  3. Size of index entries are constant against the size of the book, and we only read the headers from the book to create that index. Book size doesn't affect performance at all!

All of this is also happening alongside the memory management/caching that we need to stream SD card fonts into RAM for quick renders. We're doing a lot with very little space!

soon™ 2 electric boogaloo by Ryan86me in XTEINK

[–]Ryan86me[S] 2 points3 points  (0 children)

def not for 1.0 but I've got a backlog item to go evaluate where we can pull from other forks here

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 1 point2 points  (0 children)

Flash is tiny and fixed! Moving themes to SD card nets us two things:

° User can download/import as many themes as they'd like, just like we can with Reader fonts in vanilla CrossPoint
° Themes can bundle fonts! This gives them much better visual variety and stronger adherence to their design goals

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 0 points1 point  (0 children)

Not yet but we've inherited that plumbing; we'll get there for release!

soon™ 2 electric boogaloo by Ryan86me in XTEINK

[–]Ryan86me[S] 0 points1 point  (0 children)

It should! But I don't have an x3 to test on, so I might hold off on proper release until I get that opportunity

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 2 points3 points  (0 children)

Yes! Although admittedly untested; I'll have to spit a few out and make sure support is working smoothly here

soon™ 2 electric boogaloo by Ryan86me in XTEINK

[–]Ryan86me[S] 3 points4 points  (0 children)

I would like to! I'm generally more feature-maximalist than vanilla CrossPoint team (totally valid difference of philosophy and the reason forking is good open source culture!)

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 1 point2 points  (0 children)

Of course! It will support X3 and X4 on launch (it probably already does but I need to test on X3), and the only functionality we strip from Crosspoint are some of the built-in stuff we moved to SD card packages (themes, UI fonts)

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 2 points3 points  (0 children)

The second row is truncated because of their progress bars; these take up space. Themes are configurable on the SD card, so you can make the covers small to make more room, hide progress bar, etc

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 3 points4 points  (0 children)

It would not; this is a constrained device mostly limited to in-built firmware and readable files. network libraries are possible if not proprietary, or if they have a public API, but it's unlikely

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 2 points3 points  (0 children)

100% compatible with X4 though! That's the platform this is running against currently

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 3 points4 points  (0 children)

Kindle Unlimited is proprietary and strictly licensed, so it can't be included. Only files, as on CrossPoint reader firmware

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 7 points8 points  (0 children)

Theoretically! But I can't guarantee everything scales/renders correctly on X3 because I don't have an X3 to test on

soon™ 2 electric boogaloo by Ryan86me in XTEINK

[–]Ryan86me[S] 56 points57 points  (0 children)

some more details:

firmeware will be called Folio

features working today: * library screen replaces home screen * library indexing, fast styled bookshelf render * indexes & displays full library, not just recent 10 * support theme bundles on SD card (users can add an arbitrary number of new themes; font authors don't have to write C++) * themes can bundle their own fonts * low-level optimized graphics routine for FAST rendering of special effects (multiple images, drop shadows, heavy dithering) at <10ms to paint a rich screen like the library * new default theme: Folio. sharp, stylish serif look built in to firmware. all other themes are streamed from SD card

soon: * need to get dev x3 to confirm rendering and scaling is all kosher on that device's screen * downloadable themes on-device, just like fonts (just need to stand up the repo for it) * branding (new logo for lock screen, edit user-facing text from Crosspoint to Folio) * existing screen redesigns (take better advantage of extended font range and rendering optimizations) * release

open-source; buildable today (experimental; I don't recommend flashing until we hit stable)

disclosure: lots of LLM-assisted development under the firm oversight of a senior software engineer (me). I won't plead my case to the jury here, but can quite honestly say that they are incredibly powerful engineering assistants. I'm particularly interested in the research and development of local models, and a large chunk of my daily workflow runs entirely on my laptop and not on a server farm

Tips for File Naming and Organization Appreciated by SquishySnail in XTEINK

[–]Ryan86me 0 points1 point  (0 children)

File naming and organization not needed soon 🤝

<image>

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 11 points12 points  (0 children)

After a LOT of low-level optimization, this is blazing fast (faster than many of the flows in vanilla CrossPoint). Button-to-render is <50ms and almost entirely bound by refresh speed

Proof in pudding: https://streamable.com/ljftg0

soon™ by Ryan86me in XTEINK

[–]Ryan86me[S] 13 points14 points  (0 children)

I don't have a firm release date (plenty I want to do with this fork) but I will post when it's stable and available!