Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Nov 24, 2025

Request to replace Processing framework to enable web support (TeaVM) and Android platforms.

Current Situation

Processing is deeply integrated across 31+ files (~5,500 LOC):

  • Core rendering: Applet extends PApplet, all graphics via PGraphics
  • Image/Font: PImage, PFont throughout
  • Events: Processing's MouseEvent, KeyEvent
  • Shaders: PShader for OpenGL shaders

Processing is desktop-only and cannot be compiled to:

  • Web/JavaScript via TeaVM (uses native OpenGL, AWT, Swing)
  • Android (uses desktop-specific APIs)

Migration Options

Option 1: libGDX (Recommended for Multi-Platform)

  • Pros: Mature, well-tested, supports Desktop/Android/iOS/Web
  • Cons: Different API than Processing, learning curve
  • Web support: Via GWT or TeaVM backend
  • Effort: Major refactor, but proven cross-platform solution

Option 2: Custom Abstraction Layer

  • Create rendering interface with multiple backends:
    • Desktop: LWJGL or Processing
    • Web: WebGL via TeaVM
    • Android: OpenGL ES
  • Pros: Full control, can preserve existing API
  • Cons: Significant development effort, maintain 3 backends

Option 3: Processing.js / p5.js for Web

  • Keep Processing for desktop
  • Use p5.js for web (JavaScript port)
  • Pros: Similar API, less code changes
  • Cons: Separate codebases, no Android solution

Platform Support Comparison

Target LWJGL libGDX Custom
Desktop
Web (TeaVM) ✅ (complex)
Android ✅ (complex)
Effort High Medium-High Very High

Note: LWJGL alone won't solve web/Android - it's desktop-only. For multi-platform, libGDX is the more practical choice.

Recommendation

For web + Android support, consider libGDX as it:

  1. Has proven TeaVM/GWT web backends
  2. Supports Android natively
  3. Provides similar sprite/stage concepts
  4. Has active community and documentation

Next Steps

  1. Confirm target platforms (Web via TeaVM, Android, keep Desktop)
  2. Decide on framework (libGDX vs custom)
  3. Define API compatibility requirements
  4. Create migration plan with milestones
Original prompt

I want to replace processing with LWJGL. What do I need to do?


💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Copilot AI self-assigned this Nov 24, 2025
@vercel
Copy link

vercel bot commented Nov 24, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
scratch-for-java-ba8s Ready Ready Preview Comment Nov 24, 2025 9:41pm

Copilot AI changed the title [WIP] Replace processing with LWJGL Analysis: Replace Processing with LWJGL Nov 24, 2025
Copilot AI requested a review from mikebarkmin November 24, 2025 21:45
@mikebarkmin
Copy link
Member

@copilot I want to support the web with teawm and maybe android.

Copy link
Contributor Author

Copilot AI commented Nov 24, 2025

@copilot I want to support the web with teawm and maybe android.

For web (TeaVM) and Android support, LWJGL alone won't work - it's desktop-only with native bindings.

Better options for your goals:

  1. libGDX (recommended) - Proven cross-platform framework with:

    • Web support via TeaVM/GWT backends
    • Native Android support
    • Desktop support
    • Similar sprite/rendering concepts
  2. Custom abstraction layer - Define a rendering interface with separate backends for each platform (more work, but full control)

Would you like me to proceed with a libGDX migration plan, or do you have a specific framework in mind for the cross-platform support?

Copilot AI changed the title Analysis: Replace Processing with LWJGL Analysis: Replace Processing for Web (TeaVM) and Android Support Nov 24, 2025
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.

2 participants