Porting egui to ereaders. Issue with text sizes after update from 13.1 to 27.2

[Szybet]

Hello
I'm trying to port egui to eink devices using FBInk as the backend. Based on this I was able to achieve some good results:

The issue I was having was the small UI size as you can see. I decided to update egui from 13.1 to 27.2 and now text sizes are not calculated:

[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] Printing out string: "File" at pos [10.0 11.0] with size [0.0 0.0]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] galley rect: [[0.0 0.0] - [0.0 0.0]]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] Printing out string: "Side Panel" at pos [8.0 26.0] with size [0.0 0.0]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] galley rect: [[0.0 0.0] - [0.0 0.0]]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] Printing out string: "Write something: " at pos [8.0 38.0] with size [0.0 0.0]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] galley rect: [[0.0 0.0] - [0.0 0.0]]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] Printing out string: "Hello World!" at pos [20.0 38.0] with size [0.0 0.0]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] galley rect: [[0.0 0.0] - [0.0 0.0]]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] Printing out string: "Increment" at pos [12.0 59.0] with size [0.0 0.0]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] galley rect: [[0.0 0.0] - [0.0 0.0]]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] Printing out string: "https://github.com/emilk/egui/" at pos [100.0 1022.0] with size [0.0 0.0]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] galley rect: [[-0.0 0.0] - [0.0 0.0]]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] Printing out string: "egui template" at pos [208.0 32.0] with size [0.0 0.0]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] galley rect: [[0.0 0.0] - [0.0 0.0]]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] Printing out string: "https://github.com/emilk/egui_template" at pos [208.0 35.0] with size [0.0 0.0]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] galley rect: [[0.0 0.0] - [0.0 0.0]]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] Printing out string: "Source code." at pos [208.0 38.0] with size [0.0 0.0]
[2024-05-01T07:18:58Z DEBUG egui_fbink::backend] galley rect: [[0.0 0.0] - [0.0 0.0]]

The code is here, the logs are from here and calling of next egui frames is here. The example app is here but it shouldn't matter.

Thanks!

[Szybet]

I backported to egui 0.25.0 and epi 0.15.0 and the issue remains

[Szybet]

I rechecked everything too many times, this must be an issue with egui...

[haricot]

I find this interesting and a sympa llm perhaps offered me an explanation, even if I did not manage to compiled the program and I do not have an e-reader, I can suggest this to be taken with a grain of salt:


The main idea is to use the size_px field of the FBInkOTConfig structure to specify the text size in pixels, using the information provided by egui and the pixels_per_point to make the appropriate conversion, rather than using size_pt which specifies the size in points.

According to the FBInk documentation, size_px takes precedence over size_pt when both are specified. So by setting size_px you can precisely control the text size in pixels, which is important for proper integration with egui.

After reviewing the provided source code, it appears that the main issue is with how text sizes are calculated and passed to FBInk. Here are some suggestions to resolve this issue:

1. Check pixels_per_point configuration: Make sure the pixels_per_point value is correctly set and passed to egui. In the current code it is set to 1.0, but this may not match your screen resolution.

2. Use egui's text rendering functions: Instead of trying to manually calculate the text size and render it directly with FBInk, use the text rendering functions provided by egui. This will ensure that text sizes are calculated correctly.

unsafe fn fbink_print_text(
    fbfd: c_int,
    galley: &egui::text::Galley,
    text_shape: &egui::TextShape,
    fbink_cfg: &FBInkConfig,
    ppp: f32,
) -> c_int {
    let mut fbink_ot: FBInkOTConfig = std::mem::zeroed();
    let mut fbink_ot_fit: FBInkOTFit = std::mem::zeroed();

    let rect = galley.rect;
    let x = (rect.min.x * ppp) as i32;
    let y = (rect.min.y * ppp) as i32;
    let width = (rect.width() * ppp) as i32;
    let height = (rect.height() * ppp) as i32;

    fbink_ot.margins.left = x as i16;
    fbink_ot.margins.top = y as i16;
    fbink_ot.margins.right = (x + width) as i16;
    fbink_ot.margins.bottom = (y + height) as i16;
    fbink_ot.size_px = height as u16;

    let text = galley.text();
    let cstr = CString::new(text).unwrap();

    fbink_print_ot(
        fbfd,
        cstr.as_ptr(),
        &fbink_ot,
        fbink_cfg,
        &mut fbink_ot_fit,
    )
}

Shape::Text(text_shape) => {
    let galley = text_shape.galley.text();
    unsafe {
        if fbink_print_text(
            self.fbink_backend.fbfd,
            &galley,
            &text_shape,
            &self.fbink_backend.fbink_cfg,
            ppp,
        ) < 0 {
            error!("Failed to print string");
        }
    }
}

The std::mem::zeroed function was introduced in Rust 1.28, which means that for earlier versions of Rust it was not available. By using std::mem::transmute, the code can work with older versions of Rust.

However, starting with Rust 1.28, it is recommended to use std::mem::zeroed because it is a safer and more explicit way to initialize a structure with zeros. Here's how you can modify the code to use std::mem::zeroed:

let mut fbink_ot: FBInkOTConfig = std::mem::zeroed();
let mut fbink_ot_fit: FBInkOTFit = std::mem::zeroed();

This approach is cleaner and safer because it ensures that structures are correctly initialized with zeros, without having to worry about the size or alignment of the structures.

If you are using a recent version of Rust (1.28 or higher), it is recommended to use std::mem::zeroed to initialize structures. Otherwise, you can continue to use std::mem::transmute for compatibility with older versions of Rust.

[Szybet]

Thanks, I will implement this code soon

As for text size, I can't get it to be bigger no matter the pixels_per_point. the only thing changed is the background rect. I also sometimes get [2024-05-04T09:56:00Z WARN epaint::texture_atlas] epaint texture atlas overflowed!. The text size stays the same... I hoped this would fix itself after moving to recent egui version (and eframe, I dropped epi)

[haricot]

We should be able to do this:

To change the text size, you can modify this line of code by multiplying or dividing by a scale factor. For example, to increase the text size by 50%, you can use:
fbink_ot.size_px = ((galley.rect.height() * ppp * 1.5) as u16);

Or, to decrease the text size by 25%, you can use:
fbink_ot.size_px = ((galley.rect.height() * ppp * 0.75) as u16);

These pieces of code from the struct RawInput seem apropos:

egui/crates/egui/src/data/input.rs

Lines 14 to 20 in ded8dbd

	/// All coordinates are in points (logical pixels) with origin (0, 0) in the top left .corner.
	///
	/// Ii "points" can be calculated from native physical pixels
	/// using `pixels_per_point` = [`crate::Context::zoom_factor`] * `native_pixels_per_point`;
	#[derive(Clone, Debug, PartialEq)]
	#[cfg_attr(feature = "serde", derive(serde::Deserialize, serde::Serialize))]
	pub struct RawInput {

and for texture atlas overflowed:

egui/crates/egui/src/data/input.rs

Lines 37 to 42 in ded8dbd

	/// Maximum size of one side of the font texture.
	///
	/// Ask your graphics drivers about this. This corresponds to `GL_MAX_TEXTURE_SIZE`.
	///
	/// The default is a very small (but very portable) 2048.
	pub max_texture_side: Option<usize>,

The warning epaint::texture_atlas] epaint texture atlas overflowed is emitted by egui when the texture atlas used to store font glyphs has exceeded its maximum capacity.

The texture atlas is a large image in which egui stores the font glyphs (characters) needed to render text. When you render text, egui retrieves the corresponding glyphs from the texture atlas.

However, the texture atlas has a limited maximum size, usually 2048x2048 pixels. If you try to render too many different glyphs (for example, by using many fonts or displaying a lot of text with unusual characters), the texture atlas can fill up and overflow.

This warning indicates that the texture atlas has reached its maximum capacity, and some glyphs could not be stored. This can lead to rendering issues, such as missing characters or glyphs being replaced by fallback characters.

There are several ways to resolve this issue:

1. Reduce the number of fonts used: If you're using many different fonts, try to reduce the number to minimize the required glyphs.
2. Use simpler fonts: Complex fonts with many glyphs (such as fonts with non-Latin scripts) can fill up the texture atlas more quickly. Try using simpler fonts if possible.
3. Increase the texture atlas size: You can try increasing the maximum size of the texture atlas by modifying egui's source code. However, this may impact performance and memory usage.
4. Implement an on-demand font loading system: Instead of loading all fonts and glyphs upfront, you can implement a system that loads glyphs on-demand as they're needed. This can help reduce memory usage and avoid texture atlas overflows.

If this warning occurs frequently in your application, it's recommended to try the above solutions to resolve the issue and prevent text rendering problems.

[Szybet]

the first part won't work because other parts of the UI would need to be scaled too which will spawn more problems that it solves

As for the warning, well thanks AI for the explanation. Is it AI looking through code or you?

[Szybet]

Another issue i have:
How do I create a eframe::Frame? info storage from that struct are private and I need this struct for App::update. For now I just edited the library directly, but this requires doing that on every library download

[Szybet]

stop spreading misinformation...

he deleted it, at least that