CRGB Namespace Migration Plan

Overview

Migrate the CRGB class and related color types from global namespace to fl namespace, following the established pattern from EOrder and RGBW migrations.

Current State Analysis

Files to Review

src/crgb.h - Main CRGB class definition

Dependencies to Map

CRGB class methods and operators
CHSV class and HSV<->RGB conversions
Color constants (CRGB::Red, CRGB::Blue, etc.)
Pixel type aliases (e.g., CRGB*, pixel arrays)
Color utility functions that operate on CRGB/CHSV

Migration Strategy

Phase 1: Create Canonical fl Namespace Version

Create src/fl/crgb.h
- use cp to copy the contents of src/crgb.h into src/fl/crgb.h
- Move core CRGB class definition to fl namespace
- Include all operators (+, -, *, /, etc.)
- Include all color constants (Red, Green, Blue, etc.)
- Include blend functions and color manipulation methods

Phase 2: Update Global Headers for Backward Compatibility

Update src/crgb.h
- Include fl/crgb.h
- Add type alias: using CRGB = fl::CRGB;
- Add global constant aliases for color constants
- Add global function wrappers where needed

Phase 3: Handle Special Cases

Color Constants
- Ensure CRGB::Red, CRGB::Green, etc. continue to work
- May require using fl::CRGB::Red; style imports
- Alternative: Global constants like const CRGB Red = fl::CRGB::Red;
Template Functions
- Review template functions that accept CRGB parameters
- Ensure they work with both global and namespaced types
- May need template specializations or SFINAE
Array and Pointer Types
- Ensure CRGB*, CRGB[] continue to work seamlessly
- Verify LED strip array declarations remain compatible

Step 5: Comprehensive Testing

Run full test suite
Compile all examples
Performance verification

Risk Mitigation

Potential Issues

Template Compatibility - Templates expecting global CRGB may need updates
Static Member Access - CRGB::Red style access must continue working
Operator Overloads - Binary operators between global and namespaced types
Performance - Aliasing should not introduce overhead

Mitigation Strategies

Gradual Migration - Implement and test one component at a time
Comprehensive Testing - Test both old and new usage patterns
Template Specialization - Add specializations if needed for compatibility
Performance Monitoring - Benchmark before and after migration

Success Criteria

All 91 unit tests pass
All Arduino examples compile successfully
No performance regression
Full backward compatibility maintained
New fl:: namespace usage works correctly
Zero breaking changes for existing user code

Dependencies

This migration depends on the successful completion of:

✅ EOrder namespace migration
✅ RGBW namespace migration
✅ Build system stability

Timeline Estimate

Research and planning: 1-2 hours
Core implementation: 3-4 hours
Testing and validation: 2-3 hours
Edge case resolution: 1-2 hours

Total estimated time: 7-11 hours

3.1 KiB Raw Permalink Blame History