Andreas_Rozek

Most recent activity

• Forum still uses HTTP rather than HTTPS

  @Andreas_Rozek started

  • 18 comments
  • 2,431 views

  @parasquid replied
• Change forum to GitHub Discussions?

  in General • 1 year, 1 month

  

  Well,

  as someone who "runs with the hare and hunts with the hounds", I came in contact with many discussion forums in the past few months. My personal conclusion - from a user's point of view(!):

  • this forum is not that bad - in fact, its among those I like most: it is not crowded with icons and colors, provides a good hierarchical overview of topics, let's readers search for what they need and offers enough "gamification" options to keep post authors in line
    
  • I hate "discord" (which may be good for real-time chatting, but serves badly as a searchable forum) and avoids it whenever possible
    
  • I also don't like GitHub discussions, as GitHub injects technical hints and reports (such as "this issue was mentioned by ..." including badges with the state of their own issue) which may be good for developing in a team, but is just disturbing in a forum. Not mentioning the detail, that it is not shown, if a later post is a direct answer of an earlier one. And that it informs me about any changes in any thread I ever posted in - diluting the relevance of the notification badge which informs me about new issues in my own repositories. I'm working with GitHub almost every day - but I always try to avoid GitHub discussions...
    
    

  On the other hand, "discourse" looks like a noteworthy alternative as it provides a clear user interface not unlike this forum.

  With greetings from Germany,

  Andreas Rozek

• g.drawPoly/fillPoly have a limit of 64 nodes

  @Andreas_Rozek started

  • 5 comments
  • 846 views

  @allObjects replied
• Change forum to GitHub Discussions?

  in General • 1 year, 3 months

  

  I know Discourse from Node-RED and can definitely agree.

  However, AFAIK, Gordon wanted to avoid having to maintain a forum himself, which is why he looked at GitHub Discussions...

• Understanding how to show seconds and minutes properly

  in Bangle.js • 1 year, 3 months

  

  I don't think so

  If you change intervals seldomly, setInterval may consume a little less power - but compared to what you need for drawing your screen contents, you should never be able to recognize the difference.

• Understanding how to show seconds and minutes properly

  in Bangle.js • 1 year, 3 months

  

  No,

  do not mix both approaches! Either use setTimeout as shown above or start a new setInterval whenever your drawing period changes:

  var TimerId = setInterval(draw,1000)
  ...
  clearInterval(TimerId)
  TimerId = setInterval(draw,60000)
  

• Understanding how to show seconds and minutes properly

  in Bangle.js • 1 year, 3 months

  

  Well,

  I usually prefer a construction like

  var Interval = 1000;
  setTimeout(()=>{
    draw();
  }, Interval - (Date.now() % Interval));
  

  if

  • (calculation and) drawing may take longer than 1000ms (should be
    rare) or
    
  • the Interval may change dynamically (e.g. depending on screen lock)
    
    

  But, most often, a simple setInterval should be sufficient.

• Change forum to GitHub Discussions?

  in General • 1 year, 3 months

  

  Well,

  I don't think you should judge your user's opinions just by the posts in this topic.

  To use myself as an example: being critical (e.g., in terms of privacy and GDPR compliance) does not necessarily means "dissent" - it's just that I want to avoid running into troubles by not having looked at the consequences of this switch.

  On the other side: since I am participating in a GitHub discussion (on the new GitHub "achievement" badges), I definitely prefer the existing forum!

• performance tips for computations on an ESP32

  @Andreas_Rozek started

  • 48 comments
  • 5,319 views

  @maze1980 replied
• performance tips for computations on an ESP32

  in ESP32 • 1 year, 4 months

  

  Well,

  that's indeed an interesting finding, but I doubt that it would have a significant effect on performance:

  • computeDiffusion does a lot of computations and rounds in the end only - replacing it by + 0.5 and relying on internal truncation and clamping would probably not be faster but less intuitive. However, rounding (of small values) is important for the final display any may therefore not just be omitted completely
    
  • computeHeating does not have any noticeable effect on the overall speed (it deals with 16 pixels only, not 256)
    

  • prepareDisplay rounds indices into an array only - and this cannot be omitted as you may easily test yourself

    var Test = [0,1];
    print(Test[0.5]);
    

  outputs undefined rather than 0 or 1.

  Anyway, thanks for your effort!