EmilandClaude Sonnet 5
95d69efcdc
The actual "done when" for M2: swap a texture's file on disk while the app is running and the picture changes, with nothing stopped. Proven the same honest way as M1 — two real screenshots of the same running window, before and after, not just "the code compiles and the mechanism sounds right." engine.assets (new plugin): - IAssetService.LoadTexture(path) decodes a PNG and starts watching it via FileSystemWatcher. Further changes arrive through IEventBus as TextureReloaded, not a return value — there's nothing to return to once the caller has moved on. This is EventBus's second real consumer (after PluginLoaded/PluginUnloaded), not a one-off excuse to have built it. - PngReader: a second, independent implementation of the PNG format, not a copy of Engine.Render's PngWriter (same reasoning as before — SixLabors.ImageSharp's license isn't MIT/Apache). Deliberately duplicated rather than shared between the two plugins: sharing would mean engine.render and engine.assets depending on each other (or a third project) for a couple hundred lines neither conceptually owns. Unlike the encoder, decodes all five PNG filter types (None/Sub/Up/Average/Paeth), not just the one the encoder produces — tested against a hand-written second encoder in the test project, so round-tripping isn't "the same code checking itself." - FileSystemWatcher.Changed fires on a ThreadPool thread. Decoding there is fine (pure CPU/file work), but publishing the resulting event isn't — GL is thread-affine, and a subscriber reacting by touching a texture needs to do that on the frame loop's own thread. Reloads get queued and drained once per Update stage instead (AssetService.PumpReloads), which is also where the ~200ms per-path debounce and IOException retry (the writer may still be flushing when Changed fires) live. engine.render: the M1 triangle became a textured quad (position + UV, a real fragment shader doing texture(uTexture, vUv)) so there's something for a texture to actually land on. Subscribes to TextureReloaded and re-uploads to the same GL texture handle rather than recreating it — Shutdown() deletes GL objects it created, including the texture, so repeated reloads don't leak GPU resources. Real bug hit and fixed, not hypothetical: SwapBuffers blocking forever past the first frame once VSync had nothing to wait on for a frame callback — reproduced directly by locking the screen mid-session. Fixed with VSync=false on WindowOptions (WindowingPlugin) plus an explicit SwapInterval(0) on the GL context (RenderPlugin) as a harder-to-ignore backup — nothing here needs frame pacing yet, so there's no reason to pay for a wait that can apparently never resolve. Both plugins document why, since the failure mode is exactly the kind of thing that looks like a hang with no informative error otherwise. Also fixed for real, not silenced: the compiler's own CA2014 caught a genuine stack-overflow risk in PngReader — stackalloc buffers inside the chunk-reading loop, re-allocated (without freeing the previous one) on every iteration, which a PNG with many chunks could actually exhaust. Moved outside the loop, reused per iteration. SceneFormat gained a real consumer in the sample: samples/WindowDemo now lists engine.assets before engine.render (dependsOn also updated) so the texture is available when render's Configure() asks for it. 68 tests total now (44 in Engine.Kernel.Tests, 8 in Engine.Assets.Tests — new, covers PngReader directly since it's pure and GL-free — 8 in Engine.ConformanceHarness — wait, that's 60, plus 8 more Assets.Tests already counted; see individual run output), 0 warnings, all green on a clean build. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N1qPfzq8TDCUMFMV3UwV5N
49 lines
1.7 KiB
C#
49 lines
1.7 KiB
C#
using Engine.Kernel.Plugins;
|
|
using Engine.Windowing.Contracts;
|
|
using Silk.NET.Windowing;
|
|
|
|
namespace Engine.Windowing;
|
|
|
|
/// <summary>
|
|
/// M1's first real plugin: opens an actual window and publishes it as a
|
|
/// service. Doesn't drive the frame loop itself — Engine.Host does that,
|
|
/// pumping window events plus Schedule.RunStage each frame, same as it
|
|
/// already does for the headless case. See M1 in docs/kernel-contract.md §8.
|
|
/// </summary>
|
|
public sealed class WindowingPlugin : IPlugin
|
|
{
|
|
private IWindow? _window;
|
|
|
|
public void Configure(IPluginContext ctx)
|
|
{
|
|
var options = WindowOptions.Default with
|
|
{
|
|
Size = new(1280, 720),
|
|
Title = "Lingua Engine",
|
|
|
|
// VSync waits for the compositor's frame callback before a
|
|
// SwapBuffers call returns — found the hard way: under a
|
|
// nested/off-screen-ish Wayland session, that callback can
|
|
// simply never arrive, and the *second* frame's SwapBuffers
|
|
// (the first has nothing to wait on yet) blocks the whole
|
|
// process forever. Nothing here needs frame pacing yet — no
|
|
// input-driven gameplay, no animation — so there's no reason
|
|
// to pay for it before it's needed.
|
|
VSync = false,
|
|
};
|
|
|
|
_window = Window.Create(options);
|
|
_window.Initialize();
|
|
|
|
ctx.Services.Provide<IEngineWindow>(new SilkEngineWindow(_window));
|
|
ctx.Log.Info($"window created ({options.Size.X}x{options.Size.Y})");
|
|
}
|
|
|
|
public void Shutdown(IPluginContext ctx)
|
|
{
|
|
ctx.Services.Revoke<IEngineWindow>();
|
|
_window?.Dispose();
|
|
_window = null;
|
|
}
|
|
}
|