Scrolling text support

Question

Scrolling text support

konstk1 opened this issue 3 years ago · 14 comments

Any suggestions on the best way to implement scrolling text? It doesn't look like off-screen canvas that is available in the vendor library is exposed.

Answer 1 · 2022-02-02T02:50:05.000Z

Hey @konstk1 sorry for the delay in response. I've yet to implement scrolling text myself but presumably it should be possible using sync hooks.

e.g. some very bad pseudo-code:

matrix.afterSync((_, dt, t) => {
  matrix.drawText(.., <x-position calculated according to time 't'>, ...);

  setTimeout(() => matrix.sync(), 0);
})

If I get the chance anytime soon I'll try it myself and get back to you.

Answer 2 · 2022-02-02T13:57:39.000Z

Does drawText() support negative coordinates to scroll the text off-screen?

Answer 3 · 2022-02-03T19:42:42.000Z

@konstk1 I honestly can't remember but looking at the function binding there's nothing in there that prevents negative values. So if the underlying hzeller library supports it, then yes.

Answer 4 · 2022-02-26T00:10:36.000Z

how about using the native text scroller util from the underlying hzeller library? Is there an easy way using this library to trigger util functions from the underlying library?

Answer 5 · 2022-03-06T22:18:47.000Z

I was able to implement rudimentary scrolling. It does require that the text widget spans the entire screen horizontally.

I also had to split the text into small segments due to #26.

See here: https://github.com/konstk1/matrix-dash/blob/main/src/widgets/text-widget.ts

Answer 6 · 2022-03-07T06:01:09.000Z

I was able to implement rudimentary scrolling. It does require that the text widget spans the entire screen horizontally.

I also had to split the text into small segments due to #26.

Hmm 😞 this is not ideal as I would like to scroll whole sentences.
Also I would want to scroll in only a portion of the sign, ie from left to centre only to allow flexible layouts of information.

@alexeden any ideas about the above bug (#26) and/or leveraging the native text scroller util from the underlying hzeller library?

Answer 7 · 2022-03-07T17:36:48.000Z

@samturner3 Your scroll text could be as large as you want. My code automatically segments it.

Answer 8 · 2022-03-08T01:33:34.000Z

Hi @samturner3,

I have written an npm package that sits on top of Alex's that takes care of managing sections of the board separately and adds some basic effects like scrolling and flashing and adds image support. I also extended it to draw polygons and fill in shapes you define.

It takes a declarative approach rather than a stepwise, functional approach. I wanted it to be reusable in some of my other projects. Scoreboards, network monitors, etc.

Here's a demo where I'm scrolling on only half the board like you're asking. Maybe it would be useful. wesleytabaka/rpi-led-matrix-painter-example

The library itself is published on npm under rpi-led-matrix-painter.

Answer 9 · 2022-03-08T07:49:29.000Z

Hi @samturner3,

I have written an npm package that sits on top of Alex's that takes care of managing sections of the board separately and adds some basic effects like scrolling and flashing and adds image support. I also extended it to draw polygons and fill in shapes you define.

It takes a declarative approach rather than a stepwise, functional approach. I wanted it to be reusable in some of my other projects. Scoreboards, network monitors, etc.

Here's a demo where I'm scrolling on only half the board like you're asking. Maybe it would be useful. wesleytabaka/rpi-led-matrix-painter-example

The library itself is published on npm under rpi-led-matrix-painter.

Thanks @wesley, got your code working however still ahve same bug as #26, any built in solution to your code?

Answer 10 · 2022-03-08T13:54:51.000Z

Hi @samturner3,
I have written an npm package that sits on top of Alex's that takes care of managing sections of the board separately and adds some basic effects like scrolling and flashing and adds image support. I also extended it to draw polygons and fill in shapes you define.
It takes a declarative approach rather than a stepwise, functional approach. I wanted it to be reusable in some of my other projects. Scoreboards, network monitors, etc.
Here's a demo where I'm scrolling on only half the board like you're asking. Maybe it would be useful. wesleytabaka/rpi-led-matrix-painter-example
The library itself is published on npm under rpi-led-matrix-painter.

Thanks @wesley, got your code working however still ahve same bug as #26, any built in solution to your code?

Hmm! I don't think I've encountered this. I'll have to break out my pi tonight and give this a try.

Answer 11 · 2022-03-09T01:24:43.000Z

Hi @samturner3,
I have written an npm package that sits on top of Alex's that takes care of managing sections of the board separately and adds some basic effects like scrolling and flashing and adds image support. I also extended it to draw polygons and fill in shapes you define.
It takes a declarative approach rather than a stepwise, functional approach. I wanted it to be reusable in some of my other projects. Scoreboards, network monitors, etc.
Here's a demo where I'm scrolling on only half the board like you're asking. Maybe it would be useful. wesleytabaka/rpi-led-matrix-painter-example
The library itself is published on npm under rpi-led-matrix-painter.

Thanks @wesley, got your code working however still ahve same bug as #26, any built in solution to your code?

Hmm! I don't think I've encountered this. I'll have to break out my pi tonight and give this a try.

I can confirm this behavior using en-US keyboard. 14 seems to be the magic length as well. This will take some time, I think. I'll need to do some research. I think I might convert my implementation for writing text to use hzeller's DrawGlyph method instead of DrawText. It seems like we're seeing this garbled text because hzeller's implementation uses Unicode.

Answer 12 · 2022-03-09T03:18:31.000Z

I can confirm this behavior using en-US keyboard. 14 seems to be the magic length as well. This will take some time, I think. I'll need to do some research. I think I might convert my implementation for writing text to use hzeller's DrawGlyph method instead of DrawText. It seems like we're seeing this garbled text because hzeller's implementation uses Unicode.

Sounds good, should we move this discussion to your repo, as no longer relevant to alexeden/rpi-led-matrix?

Answer 13 · 2022-03-09T21:17:15.000Z

I can confirm this behavior using en-US keyboard. 14 seems to be the magic length as well. This will take some time, I think. I'll need to do some research. I think I might convert my implementation for writing text to use hzeller's DrawGlyph method instead of DrawText. It seems like we're seeing this garbled text because hzeller's implementation uses Unicode.

Sounds good, should we move this discussion to your repo, as no longer relevant to alexeden/rpi-led-matrix?

I've opened wesleytabaka/rpi-led-matrix-painter#6 in my "painter" repo.

I think I need to extend alexeden/rpi-led-matrix to add the DrawGlyph method. When I've finished I'll create a PR into alexeden/rpi-led-matrix if it's helpful to others.

Answer 14 · 2022-03-09T21:27:06.000Z

I don't think the issue is with Unicode perse. The same issue happens if you use regular characters of length greater than 16. The reason you're seeing it with shorter strings that include Unicode is that those characters are more than a single byte. What I think happens is the underlying library statically allocates a buffer based on some maximum number of regular characters for the screen. When your string exceeds that, you get a buffer overflow, which corrupts the data.