Skip to content

Implement basic desktop app with chromium embeded framework #2874

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

Merged
merged 12 commits into from
Jul 23, 2025

Conversation

timon-schelling
Copy link
Collaborator

@timon-schelling timon-schelling commented Jul 13, 2025

Things done:

  • getting the frontend to work inside cef like it would be running in a browser
  • implement resource handler for bundling frontend files inside the desktop app binary

Known issues:

  • shortcuts that include a char key do not work
  • shortcuts that include a mouse press do not work
  • clipboard not working
  • poor performance for very large windows
  • GPU process sometimes crashes during resize, this can take down the whole app if it happens to frequently
    • [ERROR:components/viz/service/main/viz_main_impl.cc:184] Exiting GPU process due to errors during initialization
    • [ERROR:content/browser/gpu/gpu_process_host.cc:957] GPU process exited unexpectedly: exit_code=133
      [FATAL:content/browser/gpu/gpu_data_manager_impl_private.cc:415] GPU process isn't usable. Goodbye.
  • Some other errors
    • [ERROR:google_apis/gcm/engine/registration_request.cc:291] Registration response error message: DEPRECATED_ENDPOINT
    • Subprocess of type zygote failed

Other possible improvements:

  • rerender only dirty regions
  • use accelerated draw api
  • reduce idle cpu usage
  • refactor wgpu parts

@timon-schelling timon-schelling force-pushed the desktop-app branch 15 times, most recently from 0806b05 to 809a009 Compare July 19, 2025 19:34
@timon-schelling timon-schelling force-pushed the desktop-app branch 2 times, most recently from 5e4d5d1 to c5d0e41 Compare July 23, 2025 12:23
@TrueDoctor TrueDoctor marked this pull request as ready for review July 23, 2025 17:56
@TrueDoctor TrueDoctor merged commit 30abc92 into GraphiteEditor:master Jul 23, 2025
4 checks passed
fn main() {
let frontend_dir = format!("{}/../frontend/dist", env!("CARGO_MANIFEST_DIR"));
metadata(&frontend_dir).expect("Failed to find frontend directory. Please build the frontend first.");
metadata(format!("{}/index.html", &frontend_dir)).expect("Failed to find index.html in frontend directory.");
Copy link
Collaborator

@Firestar99 Firestar99 Jul 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain to me why this build.rs exists? Just to verify the frontend is build? Two scenarios:

  • You are embedding the frontend/dist folder in the executable: Then the embedding process should fail during build, not the build script during check.
  • You are referencing this folder from code and it will be distributed alongside the executable: Then wouldn't a simple #[test] protect against failure?
  • Also consider just building the frontend in the build script?

Background: Every cargo check, cargo test or cargo build now fails if you didn't explicitly build the frontend first.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is the first case, and for me it was just a way to provide better feedback to devs. But I didn't think about your Issue. Feel free to open a pr. Or I will take a look maybe tomorrow.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now I can just comment out the build.rs, rather you have a look cause you also know how the embedding works

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants