Aria图形库与GOL是否在beta版本中

ARI库引入了许多新的改进，但同时也去除了一些有用的特性。此外，ARI的性能显著降低，目前我发现亚里亚还不稳定。在一个页面上放置多个小部件，至少15个，执行由于内存故障而中断。



      以下为原文

    Aria library introduced many new improvements but, at the same time, removed some useful features. Moreover, Aria performance is singnificantly lower.
At the moment, I found Aria not yet stable. Placing many widget on one page, at least 15, the execution breaks due to memory fault.

那么它会是LLC类型的图形项目的建议，与和声1.xx保持一致吗？我知道也有阻力触摸和方向的问题。我也有其他项目（无图形）与MSD和SPI驱动程序的问题。



      以下为原文

    Would it then be a recommendation for LLC type graphic project to stay with Harmony 1.XX?
I know there are also issues with resistive touch and orientation as well.
I am also having issue on other project (no graphics) with MSD and SPI drivers.
 
 
 

昨天，我终于可以运行一个简单的屏幕与4 JPGS 48×48像素和谐，我得到201KB的程序内存使用和85KB的RAM。我认为这是不可接受的完整商业应用，是吗？



      以下为原文

    Yesterday I finally could run a simple screen with 4 jpgs 48x48 pixels in harmony and I got 201KB of Program Memory Used and 8.5KB of RAM. I think that's not acceptable for a full commercial application, is it?
 

嗨，在V2.04 Aria已经有了巨大的进步。它在特征和能力方面大大优于V1.XX GOL图形。图形编写器套件也显著改进，覆盖了V1.XX中工具中的所有内容。V2.xx中的升级路径与V1.XX相比更为简单。在V2.05中，我们正在添加视频流、RTOS支持、使用外部媒体的例子、对MZDA设备的完全支持，并在DigaPrimeCy.EcCasra中取得了重大的飞跃，您是否使用了V2.04中的堆估计工具来处理内存故障问题？你使用的是什么版本的和声？你在用什么工具？你能详细说明一下设置吗？我们有应用程序，如AiaLaCuffiFixMead，使用至少50个8×800×480 JPG图像并使用小于1.5 MB的程序内存。你在提到的原语中所用的所有特征都可以通过图像掩蔽或小窗口剪辑实现在ARI中。我们将在V2.05版本中增加一个改进的仪表小工具版本。总之，如果您今天开始图形开发，我强烈推荐使用ARIL和ValueV2.04。



      以下为原文

    Hi,
 
There have been huge improvements made to Aria in v2.04.  It is vastly superior to v1.xx GOL graphics in terms of features and capabilities.  The Graphics Composer suite is also significantly improved and covers everything that is in the tool in v1.xx.  The upgrade path in v2.xx is more straightforward versus v1.xx.  In v2.05, we are adding video streaming, RTOS support, examples for using external media, full support for the MZ DA device, and made a significant leap in draw performance.
 
egcasira, have you used the Heap Estimator tool in v2.04 to handle the memory fault issue?

epareja, What version of Harmony are you using?  What tool are you using?  Can you elaborate on the settings?  We have applications such as aria_coffee_maker that uses upwards 50 images with at least 8 800x480 JPG images and uses less than 1.5 MB of program memory.

All the features you have mentioned with regards to primitives can be achieved in Aria using image masking or widget clipping.  And we will be adding back a much-improved version of the meter widget in a post v2.05 release.
 
In summary, if you are starting graphics development today, I highly recommend using Aria and Harmony v2.04.

谢谢你的回答，MGGCI使用一个带有PIC32 MX795F512H的定制板来测试基于ILI9325驱动程序的一个3X240 TFT，它是和谐的。我使用的是和声2.04和MPLAB X4.05.关于原语，我想复制一个旧的例子来测试ILI9325驱动器的速度，使线和圆。我可以用GFXX拉线画一条线，但是我必须手动锁定激活层。如果我试图用GFX-DouthCy圈（x，y，半径）画一个圆；我得到一个免责错误。关于ARI库和作曲家，我知道它在开发过程中，看起来很好。现在，但是如果可能的话，我有一些关于未来版本的建议：只导入或导出SMEMS的可行性。创建一个存储库来选择不同的设计（SCEMS）。（我们都是工程师，在我的例子中，从颜色选择比处理LCD驱动器更困难……LOL）为SMEMS创建逻辑文件夹的可能性。如果有大型项目，则可以组织SHIMS。在字符串编辑器中，也可以使用逻辑文件夹来为一个屏幕或其他分组标准分组字符串。包括下拉列表框（当然，您正在处理这个列表）。轻松添加一行（虚线、破折号、实线）和线条的细长，作为矩形窗口小部件。在窗口小部件中允许一个渐变填充和字幕文本，让它配置字幕文本中填充的宽度。如何在驱动固件中使用LCD屏幕配置的方向。在图形作曲家？驱动程序说，这个方向应该由驱动程序管理，而在ARA中，它应该在作曲家中被使用，但是我没有找到使用这个方向的方法，因为它没有存储在GFxx上下文结构中。在堆计算器中，我应该定义一个19525字节的堆，但是如果我这样做，它只显示1的PNG。我应该用60来画我所附的屏幕。我还不能在PNG上显示透明度。你怎么能做到呢？谢谢您！！！！！



      以下为原文

    Thank you for your answer MHGC
I'm using a custom board with the PIC32MX795F512H to test a 320x240 TFT based on ILI9325 driver with harmony.
I''m using Harmony 2.04 and MPLAB X 4.05.
 
About the primitives, I wanted to reproduce an old example for testing the ILI9325 driver speed making lines and circles of different colors (Not using Aria).
I could draw a line using GFX_DrawLine but I have to lock manually the active layer.
   pContext = GFX_ActiveContext();
   pContext->layer.active->locked = GFX_TRUE;
   GFX_DrawLine(10,10,100,200);

If I try to draw a Circle with GFX_DrawCircle(x,y,radius); I get an exemption error.
 
About the ARIA library and composer, I know it's in development process and seems very good now, but I have a few suggestions for future releases if possible:

• Posibility to import / Export Schems only.
  
• Create a repository to choose from different designs (Schems). (We are all engineers, and in my case, choose from colors is more difficult than deal with an LCD driver.... LOL).
  
• Possibility to create logic folders for Schems. If you have large projects, it could be helpful to organize the Schems.
  
• In the Strings Editor could be also useful to have logic folders to group strings for one screen or other grouping criteria. 
  
• Include a drop down list box (sure you are working on this one though).
  
• The line and circle primitives please add a type of line (Dotted, dash, solid) and thinkness of the line, as the Rectangle Widget.
  
• In the Window Widget allow a gradient fill and the caption text let it configure the width of the fill in the caption text.
  
• How can be used in the driver firmware the orientation of the LCD screen configured in the Graphic Composer? The driver says that the orientation should be managed by the driver and in ARIA it should be cofigured in the composer, but I haven't found the way to use that orientation because it's not stored in the GFX_Context structure.
  

In the HEAP calculator it says I should define a Heap of 19525 bytes, but If I do that It only shows 1 of the PNGs. I should use 60.000 to be able to draw the screen I attach here.
 
I haven't been able to show transparency on the PNGs. How can you do that?
 
Thank you!!!!
   Attached Image(s)

MHGC：既然你谈到了2.05，你能给论坛和ETA当它可能被释放。我有很多问题与NVM和SPI驱动的PIC32 MK.谢谢。



      以下为原文

    MHGC: Since you talked about 2.05, could you give the forum and ETA when it might be released.
I have a lot of issues with NVM and SPI drivers for the PIC32MK.
Thanks.

您好，有多个对象，您的问题可能与堆设置。我们现在有一个堆估算器，可能会有帮助。您可以将堆设置为MHC中的新值，也可以在该工具内设置新值。



      以下为原文

    Hello,
 
With multiple objects your issues are likely with the heap settings.  We now have a heap estimator which might help.  You can set the heap to a new value in MHC or within that tool as well.
 

和声V2.05目前计划在年底前完成。它包含了性能改进和一些新的应用实例。但是，小部件与前一版本基本相同。



      以下为原文

    Harmony v2.05 is currently scheduled before the end of the year.  It does contain performance improvements and several new application examples.  However, the widgets are fundamentally the same as in the previous version.

我发现了很多小部件的麻烦来源。当然，这是一个内存问题，但是，堆堆的主要来源是TCP/IP堆栈而不是ARIL，所以不能很容易地使用堆估计器。此外，ARIL库不检查内存分配是否失败，这很难跟踪问题。增加堆大小解决了这个问题。在我看来，为了提高长期可靠性，只有在绝对必要时才使用动态分配。看看ARIL源，我不太高兴看到每一个触摸事件发生两个MALLC，一个静态数组的事件可能是绰绰有余。再见。



      以下为原文

    Well, I've found the source of my troubles with many widgets. Of course it is a memory problem but, it could not be easily spotted with the heap estimator because the main source of heap usage is the TCP/IP stack and not Aria!
Moreover, the Aria library does not check if the memory allocation fails, and this makes very difficult to track down the problem.
Increasing the heap size solved the problem.
In my opinion, in order to increase the long term reliability, dynamic allocation should be used only if absolutely necessary. Looking at Aria source I'm not very happy to see that for each touch event a couple of malloc take place, a static array for events could be more than enough.
 
Bye

问题是TCP/IP在开始时只做一个MalCube（），而不是静态分配。



      以下为原文

    The Issue is More that TCP/IP does a single Malloc() at the Start instead of a Static Allocation. 
The ARIA Mallocs are a different matter.

你好，MikeinAZ，谢谢你的评论。我的应用程序只使用ARI图形库，堆估计器表示19.500个字节，但是我必须上升到60个来显示我张贴在这里的屏幕（http://www. McCys.com /论坛/ FindPost / 1023464）。我去40字节堆，只有2的图像显示。



      以下为原文

   
Hello MikeinAZ and thank you for your comments. My application is using only ARIA graphic Library and the HEAP estimator says 19.500 bytes but I have to go up to 60.000 to display the screen I posted here (http://www.microchip.com/forums/FindPost/1023464). I I go to 40.000 bytes Heap, only 2 of the images are displayed.
 
 
 

您好，从您的其他评论，我相信您正在使用PNG图像。估计目前不是非常精确的PNG。因此，您的堆值可能更高（并且在您的情况下验证）大于估计值。在大多数情况下，当应用程序没有完全呈现所有对象，但为某些对象工作时，这是由于堆大小不匹配。看来你现在有这个工作了。



      以下为原文

    Hello,
 
From your other comments I believe you are using PNG images.  The estimator is not currently very accurate with PNG in particular.  So you are correct that your heap values are likely higher (and in your case verified) to be more than the estimate.
 
In a majority of cases, when an application does not fully render all objects, but works for some, it is due to heap size mismatch.  It seems like you have this working for you now.