feat(ffi): add processing_poll_events for external event loop integration

[pepc84]

Summary

Adds processing_poll_events() to the C FFI, which ticks Bevy's app one frame. This lets embedders that manage their own window and event loop advance libprocessing's internal state each frame without using the built-in runner.

Motivation

When embedding libprocessing into a native host that drives its own event loop, there is no way to tick the Bevy app from outside. The Python bindings have poll_events() on the Surface struct but this is not exposed over C.

The window system the host uses does not matter. The host creates a WebGPU surface via processing_surface_create, passes native window and display handles, and drives the frame loop itself. processing_poll_events is what advances Bevy's ECS and render world each frame in that model.

Usage

processing_init();
uint64_t surface = processing_surface_create_x11(window, display, w, h, scale);
uint64_t gfx = processing_graphics_create(surface, w, h);

while (running) {
    running = processing_poll_events();
    processing_begin_draw(gfx);
    // draw calls
    processing_end_draw(gfx);
}

Changes

• Add processing_poll_events() -> bool to processing_ffi/src/lib.rs
• Add processing_core as a direct dependency of processing_ffi since app_mut is not re-exported through processing::prelude

Notes

This builds on top of #236 since that fix is required for the crate to compile on Linux.

[tychedelia]

Thanks for this! I don't think we need it for the loop in the description: processing_end_draw already runs app.update() (via present flush), so calling this before begin_draw runs a second full update every frame. The Python Surface.poll_events() doesn't tick the app either, it pumps GLFW, forwards input, and calls input_flush(). The C equivalent is to forward your host's window events through the processing_input_* functions and call processing_input_flush(), both of which already exist. If you're seeing state that doesn't advance with that setup (e.g. frames where you skip drawing), could you describe the symptom? We'd rather add something targeted for that case

[catilac]

I think it's better to open up an issue before making changes to the core functionality. It needs to be discussed, especially by people who are newer to the project