将画图板数据保存成文件

本文介绍了图形绘制数据如何保存成文件的技术,包括自定义队列保存和仿BMP文件保存两种方法。自定义队列保存通过队列将图形信息写入文件;仿BMP文件保存则将画布上的每个点的颜色信息保存,提高了读取效率。

     前几天完成了在画图板上可以绘制一些图形,并将其保存在了一个自定义的队列中。此时,这些图形只是保存在了内存中。接下来的工作就是将画图板数据保存成文件,存储在硬盘里。

 

 第一种方法:

     利用队列,将重绘时用来保存形状对象的队列写入文件。此时,文件的格式是我们自己定义的。总的来说,不同的文件格式就是文件的信息用不同的顺序写入文件中,即,对信息的编码。文件的扩展名,对文件内信息的编码方式没有影响,只是用来方便应用程序识别文件格式,选取相应的应用程序来打开它。例如:新建一个Microsoft Word文档,它的扩展名是.doc.写入一行文字后保存。如果,去掉文件的扩展名,文件的信息仍然是存在的,只是打开时系统无法自定选择应用程序去打开这个文件,需要人去选择。如果,我们这是选择Microsoft Word去打开,仍然可以正确的打开读取。如果,我们选择txt文档去打开,仍然可以打开,只是此时读取的信息是乱码,因为 txt 文档会按照自己的解码方式 去读取文件信息,txt 解码方式和 doc不一样,txt 按照自己的解码方式翻译过来后,读取出来的对应的不是我们当初写入的初衷了。

 

 

     思路是:1,创建输出流对象。 2,首先读取图形的个数,写入文件。3,读取图形的形状写入文件。 4,根据读取的类型,创建相应的图形对象。然后,写入图形的属性。

 

    创建输出流对象时用到了基本数据输出流,因为此时写入的是一些基本的数据类型,基本数据类型有 8 个。byte=8 bit; int =4byte=32bit ; short=2byte=16bit;long =8byte=64bit; char=2 byte=16bit; float=4byte=32bit; double=8byte=64bit ; boolean=8bit;  1个汉字=2个英文字母=2byte,1个数字占一个字节。

 

    在写入文件的数据后,读取时,需要按照相同的顺序。文件的名字可以任意命名,扩展名亦是任意,也可以没有扩展名。如果,把文件的扩展名定义为 txt,那么,可以用txt 打开,不过打开后是乱码罢了,因为我们写入文件的信息顺序和txt不一样。

 

   读取文件时,新建一个队列存储信息,只要按照写入时,相同的顺序,read就好了,将读取的相应的属性赋予对象,最后,将队列遍历绘制就好了。这里面,最重要的就是 注意 写入 和读取 要有相同的顺序读取的相应的数据类型。

 

 

  第二种方法:

 

    仿照BMP文件 

 

   在第一种方法中,当要保存的形状个数特别多时,文件读取时,速度是非常慢的,仿BMP文件保存,就解决了这个问题。此时,保存时,不再以画了多少个图形为主,而是保存画布上的每一个点。因为画布大小不变时,像素点的数目是不变的,因此,就算图形个数特别多,文件读取图形重绘时,速度不会变慢。

   在仿BMP文件保存时,我们重绘的是画布上的点。声明一个数组Color[][],用来保存画布上的点的颜色,画布的宽和高,就是数组的列数和行数。得到数组后,对数组进行遍历,将点的颜色存入数组。像素点的颜色,是用RGB来定义,点的颜色的不同,就是RGB取值不同。java.awt下有一个Robot类下的createScreenCapture方法,可以抓取从屏幕中设定的矩形范围的图像。因为抓取的图像是相对于屏幕的位置,因此需要得到画布相对于屏幕的位置。JPanel有一个方法getLocationOnScreen(),可以得到画布左上角的点相对于屏幕的位置。此时,就可以设定Robot要抓取的具体位置了。抓取到图像后,就可以取得像素点的RGB值了。image.getRGB会得到一个值,存入数组,得到整个画布的像素点的分布了。

 

保存图片到文件,就是将每个点的颜色写入就好了。读取文件,正好相反,就是读取颜色,然后,绘制相应颜色的点。调用drawLine方法,绘制直线需要两个点,只要两个点坐标一样,那么就会绘制一个点了。只是,需要注意的一点就是,当按行遍历时,行数不变,列数增加,当将RGB的值赋予Color[][]数组时,横纵坐标应该是相反的。

 

这时,仿BMP文件保存,读取就完成了。

 

 

 

 

AI 代码审查Review工具 是一个旨在自动化代码审查流程的工具。它通过集版本控制系统(如 GitHub 和 GitLab)的 Webhook,利用大型语言模型(LLM)对代码变更进行分析,并将审查意见反馈到相应的 Pull Request 或 Merge Request 中。此外,它还支持将审查结果通知到企业微信等通讯工具。 一个基于 LLM 的自动化代码审查助手。通过 GitHub/GitLab Webhook 监听 PR/MR 变更,调用 AI 分析代码,并将审查意见自动评论到 PR/MR,同时支持多种通知渠道。 主要功能 多平台支持: 集 GitHub 和 GitLab Webhook,监听 Pull Request / Merge Request 事件。 智能审查模式: 详细审查 (/github_webhook, /gitlab_webhook): AI 对每个变更文件进行分析,旨在找出具体问题。审查意见会以结构化的形式(例如,位到特代码行、问题分类、严重程度、分析和建议)逐条评论到 PR/MR。AI 模型会输出 JSON 格式的分析结果,系统再将其转换为多条独立的评论。 通用审查 (/github_webhook_general, /gitlab_webhook_general): AI 对每个变更文件进行整体性分析,并为每个文件一个 Markdown 格式的总结性评论。 自动化流程: 自动将 AI 审查意见(详细模式下为多条,通用模式下为每个文件一条)发布到 PR/MR。 在所有文件审查完毕后,自动在 PR/MR 中发布一条总结性评论。 即便 AI 未发现任何值得报告的问题,也会发布相应的友好提示和总结评论。 异步处理审查任务,快速响应 Webhook。 通过 Redis 防止对同一 Commit 的重复审查。 灵活配置: 通过环境变量设置基
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值