| Maxdamantus | I don't think the resolution is going to have an effect on how long it takes to update. | 00:31 |
|---|---|---|
| Maxdamantus | unless something about the pixel density makes low-latency refreshes harder. | 00:32 |
| Maxdamantus | I would expect a terminal to update fairly quickly (resulting in ghosting) if it knows that it's scrolling through many lines of text, and when it stops scrolling, it should do a full redraw. | 00:33 |
| Maxdamantus | but I don't think a full redraw takes 1s on my kobo. | 00:34 |
| Maxdamantus | iirc takes probably less than 0.5s, but don't want to test that atm since I'm trying to get Xorg working | 00:34 |
| Maxdamantus | btw, rationale for resolution not having an effect on how long it takes to update: two e-ink devices should update in the same amount of time as one e-ink device, and two e-ink devices obviously have twice the number of pixels as one e-ink device. | 00:39 |
| Maxdamantus | so if more resolution means more time, you've just got some vertical scaling issue (eg, need more CPU power), not some issue inherent to e-ink technology. | 00:40 |
| Maxdamantus | Decent demonstration of changes in update frequency: https://youtu.be/6pw-oCItgx8?t=356 | 01:04 |
| Maxdamantus | Seems to handle text quite a bit differently to random pixel updates that occur from video: https://drive.google.com/file/d/1SLoa9XsNXRPk1UhxOo5xh3UcTlZyujQI/view | 03:55 |
| Maxdamantus | (that's doing a "partial" update of the entire screen every second) | 03:55 |
| * Maxdamantus wonders if it's possible to get have more control over the update mechanism. | 03:59 | |
| Maxdamantus | the way the updates work there is you just call some ioctl on /dev/fb0 telling it the region to update, and then presumably something compares the current state of the FB to the previously drawn FB and does some sort of cycling through values of the pixels that have changed. | 04:01 |
| Maxdamantus | dunno if that "something" is in hardware/firmware/kernel. | 04:02 |
| * Maxdamantus suspects it's in hardware/firmware. | 04:02 | |
| KotCzarny | maxd: fbtft module is intelligent one | 07:37 |
| KotCzarny | it does partial updates, but that wont help when you scroll whole screen | 07:37 |
| KotCzarny | thats why i suggested writing own terminal, with some kind of circular writing instead of scrolling | 07:38 |
| Maxdamantus | "partial" seems to have multiple meanings here. | 07:38 |
| Maxdamantus | the update mechanism provided thourg the ioctl lets you specify a region (part of the screen), but "partial" vs. "full" there denotes whether or not it should try hard to reset any pixels in the region. | 07:39 |
| Maxdamantus | so you use "full" updates when you want to avoid leaving ghosting artifacts. | 07:40 |
| Maxdamantus | but you can always update only a particular region of the screen. | 07:40 |
| KotCzarny | partial means updating only some pixels | 07:40 |
| KotCzarny | i can only tell about a13 nolimbook i have | 07:41 |
| Maxdamantus | Okay, so that's not really what "partial" means in this ioctl. | 07:41 |
| KotCzarny | there is some ioctl that just resets whole screen | 07:41 |
| KotCzarny | where you get rid of ghosting | 07:41 |
| Maxdamantus | though part of the effect of using the "partial" update is that it won't change pixels that haven't changed in the fb since the last update. | 07:42 |
| KotCzarny | i have in my todo to write some decent ebook reader | 07:44 |
| KotCzarny | because stock one is an abomination | 07:45 |
| KotCzarny | will probably have to write fb one with skipping of the x | 07:49 |
| KotCzarny | for refresh and power control | 07:49 |
| Maxdamantus | a 0.1s frequency for updates seems quite natural actually. | 09:36 |
| Maxdamantus | as long as you're not trying to play video. | 09:36 |
| Maxdamantus | can drag windows around, and obviously you get artifacts, but it's at least understandable what's going on, and the artifacts aren't that bad once you stop moving things. | 09:37 |
| Maxdamantus | might be better if I make the background white. | 09:37 |
| KotCzarny | jump scroll is best, not not all terminal apps have it | 09:38 |
| KotCzarny | lol | 09:39 |
| KotCzarny | did you seriously use white on black on eink? | 09:39 |
| Maxdamantus | Yes. | 09:39 |
| KotCzarny | lol. | 09:39 |
| Maxdamantus | hm, can't figure out how to get Xorg to not use black. | 09:39 |
| KotCzarny | -rv ? | 09:39 |
| * Maxdamantus usually just uses xsetroot, but that doesn't seem to be doing anything. | 09:39 | |
| KotCzarny | most x apps support that form | 09:39 |
| Maxdamantus | I mean the background of Xorg. | 09:40 |
| KotCzarny | add xsetbg in .xstartup ? | 09:40 |
| KotCzarny | or check what i has in default startup script in etc | 09:40 |
| KotCzarny | *it | 09:40 |
| KotCzarny | .xresources might help too | 09:41 |
| KotCzarny | and similar in etc | 09:41 |
| Maxdamantus | I'm not really running anything like that. | 09:43 |
| Maxdamantus | I'm just talking about the root background, which is set by things like `xsetroot` or presumably `xsetbg` | 09:44 |
| KotCzarny | thats xresources thing | 09:49 |
| Maxdamantus | Isn't Xresources read by programs? | 09:50 |
| Maxdamantus | really, I just mean the background .. if I run `xsetroot -solid white` on my regular system, it sets the background to white, since I'm not running any fancy desktop program (eg, gnome-desktop or whatever) in front of it. | 09:51 |
| Maxdamantus | Oh, xfwm4 puts something in front of it. | 09:54 |
| Maxdamantus | ah, because it defaults to acting as a compositor. | 09:55 |
| Maxdamantus | https://maxdamantus.eu.org/inkoff.jpg | 13:01 |
| Maxdamantus | Seems pretty usable as a tablet. | 13:02 |
| Maxdamantus | just need a better WM. | 13:02 |
| Maxdamantus | the artifacts aren't even that bad when just doing partial updates. | 13:02 |
| Maxdamantus | Could probably just run some basic program using the X11 damage extension to figure out when to do the full updates, which would probably be something like two seconds since the last update. | 13:04 |
| Maxdamantus | but completely unnecessary for usability on a terminal or something, just useful in case you want to stop and read the text. | 13:05 |
| Maxdamantus | and need a web browser with a decent mobile UI. | 13:06 |
| Maxdamantus | Firefox crashes for some reason, but Midori seems pretty smooth performance-wise. | 13:07 |
| Maxdamantus | not sure why you'd need 512 MiB of RAM for reading ebooks. | 13:08 |
| KotCzarny | caching? | 13:16 |
| KotCzarny | and high res renders | 13:16 |
| Maxdamantus | Caching what? High res rendering of what? | 13:19 |
| Maxdamantus | When the content is by-design mostly static, there's not much you normally need to do of things like maintaining scene graphs or something. | 13:20 |
| Maxdamantus | The Kobo OS does have a web browser in it as a "beta" feature, so maybe they plan on turning it into something more general purpose, dunno. | 13:21 |
| Maxdamantus | (btw, that photo is of the device after it's turned off) | 13:23 |
| KotCzarny | yup, prerendering few pages etc | 13:28 |
| KotCzarny | yup, my nolimbook deepsleeps after 1-2s of activity | 13:29 |
| KotCzarny | and waking up ever few secs to see if input happened | 13:29 |
| KotCzarny | the web browser is a very trivial one | 13:29 |
| KotCzarny | on mine | 13:29 |
| KotCzarny | also, mine has 256M | 13:30 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
