图形处理问题

嗨，我相信你看到的是GLCD在从一个屏幕过渡到另一个屏幕时清除帧缓冲器。屏幕背后的最初想法是，用户可能希望每个屏幕具有不同的层配置，作曲家将提供一种简单的视觉设计方法。这与我们的GFX1库中的屏幕不同，它们只是小部件的不同配置。但是，在GLCD，在Layer-BuffRealDead函数下，你会发现一个双循环，一旦创建一个层缓冲区，它就可以清除一个层缓冲区。GFX堆栈的原始模型是动态分配帧缓冲器。这意味着你可以有一个单一和双缓冲层的组合，它只会根据需要使用尽可能多的内存。然后，当您转换到另一个屏幕时，不需要的空间可以被释放以供其他使用。GLCD为其帧缓冲器具有硬编码DDR地址，因此这种动态功能是不必要的。然而，Layer-BuffeDead的GLCD实现是在它们被创建时写入到透明帧缓冲区的。这可能是不可取的。我建议先删除双循环，看看它是否保留了帧缓冲器的旧内容，以便过渡看起来更平滑。栈还需要加强，以避免不必要的层重分配/重新分配，如果尺寸匹配，等等。这是一个可行的替代屏幕过渡，我知道一个设计，现在使用这一点，取得了良好的效果。这个过程是创建一个单一的屏幕，根据需要设置层，并根据需要添加/删除子和可设置的函数来添加和删除内容。在前面提到的相同设计中，第0层包含一个全屏图像控件，第1层拥有所有控件。当他们改变了“PSueDo屏幕”时，他们改变了背景图像资产指针，从第1层移除旧按钮，并为新的“屏幕”添加按钮/控件回到第1层。这个操作相当快，并且利用了不完全擦除L的提速。埃尔斯。对此的一个警告是，他们需要修改GLCD驱动程序来同步层交换。层交换目前是异步的，这导致了背景和控制的短暂失配。修改是一个讨厌的全局变量HACK，但是对层交换同步的正确支持直到2.05才会生效。如果您感兴趣，我可以提供这个代码。谢谢。



      以下为原文

    Hi,
 
I believe what you're seeing is the GLCD clearing the frame buffers as you transition from one screen to another.  The original idea behind screens was that the user may want to have different layer configurations per-screen and Composer would provide an easy way to design those visually.  This is different than the screens from our GFX1 library which were just different configurations of widgets.  Though, ideally screen transitions could and should be that simple as well. 
 
In GLCD, under the layerBufferAllocate function, you'll find a double for loop which clears a layer buffer as soon as it is created.  The original model for the GFX stack was that frame buffers would be dynamically allocated.  This meant that you could have a mix of single and double buffered layers and it would only use as much memory as needed.  Then, as you transition to another screen, unneeded space could be freed for other usage.  The GLCD has hard-coded DDR addresses for its frame buffers, so this dynamic functionality is unnecessary.  However, the GLCD implementation of layerBufferAllocate is written to clear frame buffers as they're 'created'. This is probably not desirable.
 
I would suggest first removing that double for loop and see if it preserves the old content of the frame buffers so that the transition looks more smooth. 
 
The stack also needs to be enhanced to avoid unnecessary layer deallocation/reallocation if dimensions match, etc. 
 

 
This is a viable alternative to screen transitions and I know of one design that is using this right now with good results.  The process is to create a single screen, set up the layers as needed, and use the add/remove child and setVisible functions as needed to add and remove content.
 



In that same design I previously mentioned, layer 0 contains a full-screen image widget and layer 1 has all of the controls.  When they changed 'psuedo-screens' they change the background image asset pointer, remove the old buttons from layer 1, and add the buttons/controls for the new 'screen' back to layer 1.
 
This operation is quite fast and takes advantage of the speed-up that comes from not completely wiping out your layers. 
 
One caveat to this is that they needed to modify the GLCD driver to sync the layer swapping.  Layer swapping is currently asynchronous and this caused a brief mismatch of background and controls.  The modification is a nasty global variable hack but proper support for layer swap sync won't be available until 2.05.
 
I can provide the code for this if you're interested.
 
Thanks

谢谢你。我尝试了两件事：设置Leal1，默认情况下禁用，然后启用后，飞溅屏幕完成，然后我试着设置一个完整的图层面板的顶部，并设置其可见标志关闭。在这两种情况下，在处理所有这些问题上都有明显的滞后。然而，在所有情况下，图纸是即时的。请在您有机会时提供代码。我非常感谢你的帮助！



      以下为原文

    Thanks UIG. I tried two things: set Layer1 to be disabled by default and then enabled after the splash screen completed and then I tried setting a whole layer panel on top of the layer and setting its visible flag to off. In both cases there was a noticeable lag in the time it took to process all of this. However, in all cases, the drawing was instantaneous.
 
Please provide the code when you get a chance. I greatly appreciate your help!

您报告的滞后可能是由于后台缓冲区的初始填充。缓冲区通常按需填充，亚里亚将检测何时后台缓冲区需要完全刷新。在应用程序的启动和更改屏幕时，通常需要完全刷新。此外，更改层的部分将导致这些更改在下一次绘图中被传播到后台缓冲区，以确保缓冲区保持同步。为了补偿初始的后台缓冲区填充，可以使用LaWistGug无效函数强制任何类型的对象重绘。如果你在你的应用程序开始时这样做，那么你第一次看到一个对象（例如一个按钮）就不会看到这种滞后。这将最有可能在ARI2.05中为您完成，如前所述，层交换是异步的。为了将同步性引入到您的设计中，您可以这样做：在GLCD驱动程序的顶部，我添加了：在LaysSwitter中，我补充说：注意，必须启用层VSyc选项，因为它迫使堆栈推迟到驱动程序来交换层。然后，在您的应用程序中，可以添加：当你做一个伪屏幕改变时，NDSET。在这种情况下，你会等待第1层完成。你可以做所有你想要的UI状态的改变，但是直到你等待的层（通常是最前面的层）准备好了，没有一个层会交换。同样，对这个特性的适当支持将是最有可能的2.05。如果你需要更多的信息，请告诉我。



      以下为原文

    The lag you're reporting is likely due to the initial fill of the backbuffer.  Buffers are typically filled on demand and Aria will detect when the backbuffer needs a full refresh.  A full refresh is typically needed at the start of your application and when you change screens.  Also, changing parts of the layer will cause those changes to be propagated to the back buffer on the next draw to ensure the buffers stay in sync. 
 
To compensate for the initial back buffer fill you can force any type of object to redraw using the laWidget_Invalidate function.  If you do this right at the start of your application then you won't see that lag the first time an object, a button for instance, is interacted with.  This will most likely be done for you in Aria 2.05.
 
As previously stated, the layer swapping is asynchronous.  To hack synchronicity into your design you can do it like this:
 
At the top of the GLCD driver I added:

 
// layer sync hack
int32_t glcd_waitForLayer = -1;
 

 
In layerSwapPending I added:

 
static void layerSwapPending(GFX_Layer* layer)
{
    if(glcd_waitForLayer >= 0 && layer->id != glcd_waitForLayer)
        return;
    
    glcd_waitForLayer = -1;
    
    PLIB_GLCD_VSyncInterruptEnable(GLCD_ID_0); // enable vsync interrupt
}
 

 
Note that the layer vsync option must be enabled for this to work as it forces the stack to defer to the driver to swap the layers.
 
Then, in your application you can add:
 

 
// layer sync hack
extern int32_t glcd_waitForLayer;
 

 
and
 
glcd_waitForLayer = 1;
 
Set this whenever you're doing a pseudo-screen change.  In this case you'd be waiting for layer 1 to finish.  You can make all the UI state changes you want, but until the layer that you're waiting for (usually the front-most layer) is ready, none of the layers will swap.  Again, proper support for this feature will be in 2.05 most likely.
 
Let me know if you need more information
 

在AppLIQualItLIVE函数中，我尝试了两个层上的LaWistGebug无效函数，但这对滞后没有帮助。我想我能问的最好的问题是：在我想要在屏幕上做任何事情的时候，我会一直生活在至少几百毫秒的延迟中吗？在我写这篇文章的时候，我发现用零延迟过渡的最好方式当然是在启动之后，是用alpha混合。在0到255之间似乎能把事情弄清楚。启动延迟似乎是几秒钟的顺序，但我看到屏幕需要很长时间才能运行和运行。



      以下为原文

    I tried the laWidget_Invalidate function on both layers in the APP_Initialize function, but this didn't help the the lag. I guess the best question I can ask is this: will I always have to live with delays of at least a few hundreds of milliseconds any time that I wish to do something on the screen?
 
As I write this I've found the best way to transition with zero lag, after startup of course, is to fiddle with the alpha blending. Going between 0 and 255 seems to clear things right up. The startup lag appears to be on the order of a few seconds, but I've seen screens take that long to get up and running before.

不一定。DDR在不连续写入时引入Ras/CAS等待状态引入延迟，但我们没有发现这是太有影响的。有一件事我可以建议在Gfxxx绘图函数中设置断点，如ReCT和BLIT。你可以准确地看到什么在写什么，什么时候，什么时候。如果你发现某些东西在你不打算绘制大量数据时，你可以将调用堆栈追溯到冒犯的小部件。记住2.03 ARI需要一点技巧来有效地管理绘制状态。在2.04，这个问题就少多了。通常使用2.03，如果有很多滞后，那么一些东西比它需要/应该绘制的要多，而且经常可以通过使用小部件父容器来限制。这有助于更有效地对绘制层次进行分组并消除不必要的工作。



      以下为原文

   
 
Not necessarily.  The DDR does introduce delay due to RAS/CAS wait states when writing non-sequentially but we haven't found this to be too impactful.
 
The more likely culprit is inefficiency in the Aria draw tree.  One thing I can suggest is to put breakpoints in the gfx_draw functions like rect and blit.  You can see exactly what is writing what where and when.  If you find that something is drawing a large amount of data when you didn't intend then you can trace the callstack back to the offending widget. 
 
Remember that the 2.03 Aria requires a bit of finesse to properly manage the draw states efficiently.  In 2.04 this much less of an issue.  Quite often with 2.03, if there is a lot of lag, then something is drawing more than it needs to/should and can often be limited through the use of widget parent containers.  This can help more efficiently group the draw hierarchy and eliminate unnecessary work.