{"action":"created","issue":{"url":"https://api.github.com/repos/pixelmatix/SmartMatrix/issues/25","labels_url":"https://api.github.com/repos/pixelmatix/SmartMatrix/issues/25/labels{/name}","comments_url":"https://api.github.com/repos/pixelmatix/SmartMatrix/issues/25/comments","events_url":"https://api.github.com/repos/pixelmatix/SmartMatrix/issues/25/events","html_url":"https://github.com/pixelmatix/SmartMatrix/issues/25","id":95251573,"number":25,"title":"Major Refactoring - SmartMatrix 3.x","user":{"login":"embedded-creations","id":1514796,"avatar_url":"https://avatars.githubusercontent.com/u/1514796?v=3","gravatar_id":"","url":"https://api.github.com/users/embedded-creations","html_url":"https://github.com/embedded-creations","followers_url":"https://api.github.com/users/embedded-creations/followers","following_url":"https://api.github.com/users/embedded-creations/following{/other_user}","gists_url":"https://api.github.com/users/embedded-creations/gists{/gist_id}","starred_url":"https://api.github.com/users/embedded-creations/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/embedded-creations/subscriptions","organizations_url":"https://api.github.com/users/embedded-creations/orgs","repos_url":"https://api.github.com/users/embedded-creations/repos","events_url":"https://api.github.com/users/embedded-creations/events{/privacy}","received_events_url":"https://api.github.com/users/embedded-creations/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":56,"created_at":"2015-07-15T17:50:04Z","updated_at":"2015-08-30T18:58:12Z","closed_at":null,"body":"https://github.com/pixelmatix/SmartMatrix/tree/sm3.0\r\n\r\nI'm working on a major revision to the SmartMatrix Library that simplifies the SmartMatrix Class into just refreshing the display, and moves the foreground and background layers into separate Layer classes.  Instead of using a unique header file to describe the hardware, the configuration is set in the user's sketch, so you can have one version of the library and use it with different sizes of displays.  You can create your own Layer outside of the library - for example I made a Fadecandy Layer class that I used to convert the buffers from a port of Fadecandy to SmartMatrix - and you can make your own stackup of layers, with multiple Foreground layers for example.\r\n\r\nThis requires a lot more code to set up the classes in the sketch, which I was trying to minimize with the initial release of the library, but I think this more flexible approach supports more use cases.  The code is hidden away by using a couple #defines that support the most common use cases, and we can add more.  I chose to declare buffers in the sketch instead of using malloc in the classes as I wanted the large buffers to show up in memory usage at the end of compilation, and there's no malloc support for creating DMAMEM buffers.\r\n\r\nAfter separating into classes, refactoring to be more generic (no dependencies on MATRIX_WIDTH/HEIGHT defines) and testing on both 16x32 and 32x32 panels, I found the classes worked with 32x64 with barely any changes.  I didn't get a chance to use any code from the >32x32 size pull requests from @ncortot, @GaryBoone, and @mrwastl, though maybe I will when adding support for C-shape chaining.\r\n\r\nI have the library in a decent state, and FeatureDemo has been tested on 16x32, 32x32, and 32x64 panels.  There's an occasional flicker in the 32x64 I haven't tracked down yet.  Only the FeatureDemo example is updated to use the new library, though it should be easy to update the rest. (Except for FastLED_Controller, which will need an update to the FastLED Library with SmartMatrix 3.x support)\r\n\r\nIt's probably a month or more away from an official release as I'm going to be traveling without a laptop for a couple weeks, and want to add support for more display configurations (especially C-shape paneling), to do more testing, and make some efficiency improvements after I get back.\r\n\r\nIf there are any other features you'd like to see in the next major release, let's start discussing.\r\n\r\nNot yet supported:\r\n* C-shape paneling for >32-pixel height\r\n* 24-bit (or fewer) color - this is probably best handled through C++ templates which I haven't used before, and isn't a high priority for me, let me know if it is for you (@mrwastl)\r\n* FastLED_Controller example"},"comment":{"url":"https://api.github.com/repos/pixelmatix/SmartMatrix/issues/comments/136175013","html_url":"https://github.com/pixelmatix/SmartMatrix/issues/25#issuecomment-136175013","issue_url":"https://api.github.com/repos/pixelmatix/SmartMatrix/issues/25","id":136175013,"user":{"login":"mrwastl","id":9731211,"avatar_url":"https://avatars.githubusercontent.com/u/9731211?v=3","gravatar_id":"","url":"https://api.github.com/users/mrwastl","html_url":"https://github.com/mrwastl","followers_url":"https://api.github.com/users/mrwastl/followers","following_url":"https://api.github.com/users/mrwastl/following{/other_user}","gists_url":"https://api.github.com/users/mrwastl/gists{/gist_id}","starred_url":"https://api.github.com/users/mrwastl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mrwastl/subscriptions","organizations_url":"https://api.github.com/users/mrwastl/orgs","repos_url":"https://api.github.com/users/mrwastl/repos","events_url":"https://api.github.com/users/mrwastl/events{/privacy}","received_events_url":"https://api.github.com/users/mrwastl/received_events","type":"User","site_admin":false},"created_at":"2015-08-30T18:58:11Z","updated_at":"2015-08-30T18:58:11Z","body":"@embedded-creations  why so complicated?\r\n\r\nas far as i know there're only 2 different types of panels: 32x16 and 32x32 (even the 64x32 are technically just 2 * 32x32 if i've read correctly).\r\n\r\nso you can get all information that is needed out of kMatrixHeight, kMatrixWidth and an optional kPanelHeight (which defaults to 32). and an optional chaining (with a default option (Z or C)). \r\n\r\nthe internal mapping is more or less trivial - except for one category of methods: geom. figures (drawHardware*) and for kPanelHeight = 16 (support for rotation - this led to some problems as far as i remember).\r\n\r\nor do you think about supporting more than just 'rectangular' displays (cube displays, different panels that display different content, but are controlled by one source, ...). well yes. than it would be a little bit more complicated ...\r\n\r\n\r\nsome notes to the current commits: i currently can just use 5 panels (when using 6 panels, no matter if \r\ni use `kRefreshDepth = 36` or `kRefreshDepth = 24`, the display generation crashes (when using `kMatrixWidh = 5 * 32` and `kRefreshDepth = 24` there's still ~ 20k dyn. mem left according to the arduino IDE (sketch = FeatureDemo)). when using `kRefreshDepth = 36` i can only use 4 panels.\r\n\r\nthe problem with the frozen image might be an interesting too:\r\nif i switch to git version 8efdd479706cfd7bbd5183f3e250047d05893c5a (~ april 21)  i get a frozen image too, but only with `DEMO_DRAWING_FILLED`. the pattern generation ends before the end of the scrolling text (background pattern stops, scrolling text still scrolling, scrolling text ends -> image is frozen forever). if i set `transitionTime = 4000` instead of `transitionTime = \r\n8500` than switching to the next demo is done before the end of the pattern generation and no freeze occurs (well, text scrolling is interupted though ...).\r\n(other parameters: `kMatrixWidth = 8 * 32`, `kRefreshDepth = 36`, refreshrate = 95)\r\n\r\ni didn't do these tests with reduced transitionTime with later version but i guess the cause might be similar.\r\nmaybe this helps you with debugging the frozen image problem.\r\n"}}