Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Second time's a charm =(

Second time's a charm =(

Scheduled Pinned Locked Moved The Lounge
graphicsdesigncomiottutorial
3 Posts 2 Posters 8 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • H Offline
    H Offline
    honey the codewitch
    wrote on last edited by
    #1

    I spent several days making my vector canvas able to "direct bind to a 'draw target'" if it happened to be a bitmap with a supported pixel format. I did this by extracting the pointer to the bitmap and then doing the standard (y*stride) + x*(stride/width) on it to get my final pointer. That sucks. For starters it only works with hard bitmaps. I can do better. Enter gfx_span which is a little structure with a pointer and a length. You can then do span(location).data and/or span(location).length off a bitmap to get a pointer and a length for the remainder of that row. This is important, because it opens up the blt capability (direct read/write) to more than just bitmaps. For example, my UIX library the control surface draw target does a translation and clip before writing to the backing bitmap. Without span() I cannot get a raw pointer to the backing bitmap data. I must use methods off the draw target like point() and fill() which is generally much slower - all to do that translation and clip. Unfortunately the existing code I've worked on for days will not survive this change. I have a lot of work in front of me, all because this span paradigm didn't occur to me on like, Monday. :mad: Curse my brain.

    Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

    P 1 Reply Last reply
    0
    • H honey the codewitch

      I spent several days making my vector canvas able to "direct bind to a 'draw target'" if it happened to be a bitmap with a supported pixel format. I did this by extracting the pointer to the bitmap and then doing the standard (y*stride) + x*(stride/width) on it to get my final pointer. That sucks. For starters it only works with hard bitmaps. I can do better. Enter gfx_span which is a little structure with a pointer and a length. You can then do span(location).data and/or span(location).length off a bitmap to get a pointer and a length for the remainder of that row. This is important, because it opens up the blt capability (direct read/write) to more than just bitmaps. For example, my UIX library the control surface draw target does a translation and clip before writing to the backing bitmap. Without span() I cannot get a raw pointer to the backing bitmap data. I must use methods off the draw target like point() and fill() which is generally much slower - all to do that translation and clip. Unfortunately the existing code I've worked on for days will not survive this change. I have a lot of work in front of me, all because this span paradigm didn't occur to me on like, Monday. :mad: Curse my brain.

      Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

      P Offline
      P Offline
      Phil J Pearson
      wrote on last edited by
      #2

      I find it not unusual to do quite a lot of work on something in order to find out why it's a bad idea. It takes some fortitude then to ditch it and take a new approach, but it's almost always the best plan. Also, it never seems to take so long or be such hard work the second time.

      Phil


      The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.

      H 1 Reply Last reply
      0
      • P Phil J Pearson

        I find it not unusual to do quite a lot of work on something in order to find out why it's a bad idea. It takes some fortitude then to ditch it and take a new approach, but it's almost always the best plan. Also, it never seems to take so long or be such hard work the second time.

        Phil


        The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.

        H Offline
        H Offline
        honey the codewitch
        wrote on last edited by
        #3

        Phil J Pearson wrote:

        Also, it never seems to take so long or be such hard work the second time.

        You are so right about that! I just finished retooling and testing. It's all using my new span API. Normally, I am very gifted at designing by the seat of my pants (while coding). For example my graphics library lasted years without a significant breaking change, especially to the design. I added a ton of features in that time. It's a combination of almost 4 decades of coding + some latent ability. But maybe that's why I get frustrated with myself when I miss the mark.

        Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups