Windows Imaging Component を使って背景画像を読み込み、透過描画対応 #683

beru · 2018-12-06T22:53:49Z

WICを使って背景画像用のファイルを読み込むように変更しました。

元実装では結構古くから存在する OleLoadPicture や LoadImage といったAPI関数を使って画像ファイルを読み込んでいました。

変更する利点としては対応する画像ファイルのフォーマットが増える事です。
https://docs.microsoft.com/en-us/windows/desktop/wic/-wic-about-windows-imaging-codec#native-codecs

なお、このPRの変更で背景画像のファイルパスを指定するファイルダイアログの拡張子フィルタに *.png を追加しました。有名な画像ファイルフォーマットで以前は読めませんでしたが今回WICを使うようにしたことで読めるようになりました。

背景画像の描画処理で従来は BitBlt を使って描画していましたが、透過色に対応する為に AlphaBlend を使うように変更しました。元の実装に比べると背景画像ビットマップのメモリサイズが4/3倍に増えるのと、描画する度に半透明を考慮した合成をするので処理の負荷が上がると思いますが有る程度スペックが有る現在のPCなら大きな問題にはならないかなと思います。

サクラエディタの場合、背景色がベタ一色なので事前に合成した絵を作って処理の負荷を下げる事も出来ますが行いませんでした。読み込む画像によってはアルファチャンネルが存在しないので完全な無駄にはなります…。

将来的に端末エミュレータでよくあるような後ろが透けて見える表示に対応したいと思いますが、その際に背景画像を使う事でピクセル毎に透過度を変える事が出来るので見栄えの自由度が上げられます。

透過色対応の表示例

下記のアルファチャンネルを含んだ画像を背景画像に指定した場合の表示例を出します。

https://pngquant.org/firefox-512.png

テキストの背景色を白にした場合

テキストの背景色を黒にした場合

テキストの背景色を緑にした場合

背景画像のファイルパスを指定するファイルダイアログの拡張子フィルタに *.png を追加背景画像の描画処理で透過色対応

arigayas · 2018-12-06T23:52:35Z

行番号のない赤枠の部分は画像が無い方がスマートに見えるのですがいかがでしょうか？

関連するissueは #665 でしょうか？

berryzplus · 2018-12-07T03:31:00Z

そっすね…

このPRで入れようとしてるものはかなり大きな変更です。ちょっとの変更に見せてるのはberuさんがうまいだけ。

なので、行番号背景とか描画の原点をどこにすべきかという話は分けて考えたいです。

真面目に見るつもりなんで、判断には少し時間ください。

arigayas · 2018-12-07T05:25:54Z

わかりました。
大改修ならば、行番号のない赤枠の部分は画像が無い状態にするのは、
後回し(次の次のリリース以降)になっても良いと思います。

berryzplus · 2018-12-07T06:15:47Z

誤字修正(笑

berryzplus · 2018-12-07T10:22:42Z

あれ？紛らわしい書き方ですみません。

「時間かかる」のタイムスパンは数時間のつもりです。なんとなく合意まで、1週間もかからないと予想してます。

m-tmatma · 2018-12-07T11:46:28Z

MinGW ビルドコケてます。

m-tmatma · 2018-12-07T12:53:11Z

MinGW ビルドコケてます。

master でのビルド確認のために master でビルドかけました。
https://ci.appveyor.com/project/sakuraeditor/sakura/builds/20844791

berryzplus · 2018-12-07T13:47:29Z

おっけっす。問題ないと思います。
無駄にコメントアウトされてるコードがあったり、
内容について一切コメント振ってなかったり細かいとこは色々ありますが、
「ファイルを開いて 24bit color + 8bit alpha のビットマップを作る」のに十分なコードだと思います。

では、本題に入りましょう・・・。

MinGW ビルドコケてます。

この問題について、対策できる気がするので方法は探してみます。
その前に Windows Runtime Library って win 8 以降だった気がするので、これ使うなら対象バージョンをあげなきゃいけないかもしれないです。

MinGWビルドについて、必須ではないと考えていますが、今の段階で諦めるのは早すぎると思っています。WICの実装方式もやり方がいくつかあって、WRLは１手段でしかないと考えています。

とりあえず、MinGWビルドを通す方法を（勝手に）探してみます。

MSYS2を入れた後に下記のパッケージをインストールする必要が有るようだ。(´;ω;`) mingw-w64-x86_64-headers-git mingw-w64-x86_64-crt

beru · 2018-12-07T14:04:42Z

その前に Windows Runtime Library って win 8 以降だった気がするので、これ使うなら対象バージョンをあげなきゃいけないかもしれないです。

https://github.com/Microsoft/DirectXTK/wiki/ComPtr#platform-notes

を読む限りでは多分大丈夫だと思います。鵜呑みにするのも良くないかもしれないし、ケースバイケースかもしれませんが。

berryzplus · 2018-12-07T15:17:10Z

https://github.com/Microsoft/DirectXTK/wiki/ComPtr#platform-notes

を読む限りでは多分大丈夫だと思います。鵜呑みにするのも良くないかもしれないし、ケースバイケースかもしれませんが。

調べた結果、MinGW側にも <wrl.h> は移植されていたようです。
そういえば appveyor のエラーもリンクエラーだけでしたよね。
で、その結果書こうとしたらすでにコミットが積まれてたっていう。。。＿|￣|○

いちおう、6環境ビルド確認できてから review コメントいれるつもりです。

beru · 2018-12-07T16:17:52Z

行番号のない赤枠の部分は画像が無い方がスマートに見えるのですがいかがでしょうか？

背景画像が行番号を表示する領域にまで入り込まないようにするオプションは有って良いと思います。
タイプ別設定のウィンドウの背景画像の X の Repeat のチェックを外せば解決するかというとそうでも無くて（そもそもそうすると横リピートされなくなってしまうので、させたい場合に困りますが）表示位置を中央にしてウィンドウの横幅を狭めるとやはり背景画像が行番号を表示する領域に食い込んで表示されます。

#659 で Issue を作った際に貼った画像では行番号の背景色による塗りつぶしが無くてそのまま背景画像が見えていますが、これは行番号の背景色とテキストの背景色を同じ色の設定にしていると特別に背景色による塗りつぶしが行われない隠れ仕様のようです（つい最近になって知りました）。

本題に戻って行番号表示領域ですが、行がまだ存在しない箇所（arigayasさんが赤枠で囲った場所）には背景色による塗りつぶしや行番号区切りが表示されていないですね。まだ行が無い場合でも背景色で塗りつぶすように設定出来るようにするのも良いかもしれないですね。

従来の動作も保てるように設定を増やして挙動を変えられるようにすると、設定項目がどんどんと増えていく事になるので、なかなか安易に機能追加をしにくい気がします。設定画面も改造しないといけないし…。

ちょっと話が変りますが、各所の色の設定で不透明度を指定出来ると良いですね。まぁしかしそうすると色々な箇所の描画に手を入れないといけなくなっちゃいそうなので実装は大変そうです。

beru · 2018-12-07T16:41:04Z

雑談です、というか過去の苦労話を聞いてください。

ここの target_link_libraries の２行上にも ALL_O を引数にした target_link_libraries がありますが、この２つの順番を入れ替えるとリンクに失敗するんです。スタティックライブラリに順序依存性があるなんて全く知りませんでした。

実はここの雑記は定期的に読んでいるので知らなかったはずはないのですが、自分の身に降りかかってこなければ身につかないものです。

おぉ、、なんか難しそう…。。近くにC++のテンプレートの名前解決に頭を悩ませている人がいたらぜひ息抜きに勧めてあげたい話題ですね。

そういえば国産の？Cのリンカってシンボルの定義が無かったり重複していてもリンカエラー出さないのが多かった気がします。が、今はもう使っていないので（ﾟεﾟ）ｷﾆｼﾅｲ!!

berryzplus

LGTMです。

細かいところで色々考えないといけないかも知れませんが、入れてしまって大丈夫だと思います。

berryzplus · 2018-12-08T07:31:06Z

sakura_core/doc/CEditDoc.cpp

@@ -45,6 +45,9 @@
 #include <string.h>	// Apr. 03, 2003 genta
 #include <memory>
 #include <OleCtl.h>
+#include <wincodec.h>
+#pragma comment(lib, "windowscodecs.lib")
+#include <wrl.h>


レビューコメントではないですが

この3行は StdAfx.h に移動したいな、って思ってます。

sakura/sakura_core/doc/CEditDoc.cpp

Lines 45 to 46 in 070d76a

#include <string.h> // Apr. 03, 2003 genta

#include <memory>

　γ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ヽ
　｜彡(ﾟ)(ﾟ) 彡(ﾟ)(ﾟ) あれ？ワイらは？ |
　乂＿＿＿＿＿＿＿＿＿＿＿＿＿＿_ノ

sakura/sakura_core/doc/CEditDoc.cpp

Line 47 in 070d76a

#include <OleCtl.h>

　γ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣ヽ
　｜彡(ﾟ)(ﾟ) ここにいてもいいの？ |
　乂＿＿＿＿＿＿＿＿＿＿＿＿＿_ノ

「移動」じゃなくてもいいっすよ。

まぁ #include <string.h> は削りたいです。

berryzplus · 2018-12-08T07:32:00Z

sakura_core/doc/CEditDoc.cpp

@@ -317,61 +320,70 @@ void CEditDoc::SetBackgroundImage()
 		GetInidirOrExedir( &fullPath[0], &path[0] );
 		path = fullPath;
 	}
-	const TCHAR* ext = path.GetExt();
-	if( 0 != auto_stricmp(ext, _T(".bmp")) ){


メモ： extが"bmp"と一致する場合、Bitmapを読み込んで都合よく変換する

berryzplus · 2018-12-08T07:34:37Z

sakura_core/doc/CEditDoc.cpp

-			if( iPicture ) iPicture->Release();
-		}
-	}else{
-		m_hBackImg = (HBITMAP)::LoadImage(NULL, path.c_str(), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_CREATEDIBSECTION);


メモ： extがbmpと一致しない場合、Bitmapとして「そのまま」読み込む

背景画像に指定したbmpファイルを削除できないのはこれが原因・・・（削られてますなｗ

berryzplus · 2018-12-08T07:39:25Z

sakura_core/doc/CEditDoc.cpp

-		BITMAP bmp;
-		GetObject(m_hBackImg, sizeof(BITMAP), &bmp);
-		m_nBackImgWidth  = bmp.bmWidth;
-		m_nBackImgHeight = bmp.bmHeight;


メモ：bitmapを読込できた場合、サイズ情報を取得している

読込できなかった場合の考慮はなし、メッセージもなし。

berryzplus · 2018-12-08T07:41:38Z

sakura_core/doc/CEditDoc.cpp

-		}
+
+	using namespace Microsoft::WRL;
+	ComPtr<IWICImagingFactory> pIWICFactory;


メモ： usingに注意。ComPtrの使い方はATL/MFCのCComPtrとほぼ同じです。
Atl masterの人が「違う！」と言うかもしれませんがほぼ同じです。

berryzplus · 2018-12-08T07:54:36Z

sakura_core/doc/CEditDoc.cpp

+	if( FAILED(hr) ) return;
+	hr = pConverter->Initialize(
+		pFrame.Get(),
+		GUID_WICPixelFormat32bppPBGRA,


メモ：WICのフォーマット定数はGUIDで、色々あります。
ここの例だと32bitプログレッシブBGRA(RGBではない)ですね。
intel cpuはlittle endianですが、little endian前提で 0xAARRGGBB という感じに色定義できるのがBGRA形式です。

PBGRA の P はプログレッシブではなく、premultiplied alpha を示している文字かと思います。Progressive と Djent ともまた違った関係性です。

PBGRA の P はプログレッシブではなく、premultiplied alpha を示している文字かと思います。Progressive と Djent ともまた違った関係性です。

かなり長いこと勘違いしてました。

なおAPI関数の AlphaBlend が premultiplied alpha な入力を使う仕様という事を当初把握していなくて、このPRの最初のコミットではきちんと表示されていませんでした。

自分や arigayas さんが貼り付けたスクリーンショット（自分が貼ったのは今はもう修正済み）を見て半透過部分が正しく描画されてなくて問題に気づきました。

見映えに関する修正は通りやすいですが、
見映えが変わらない変更は了解を取り付けるのに苦労します。
WIC導入は単体で大きなインパクトを与える変更です。
が、単体で入れようとすると実質何にも変わらないので入れづらいと思ってました。

描画のとこは最悪「あとで修正」も容易なのでスルーしてました・・・

berryzplus · 2018-12-08T08:01:30Z

sakura_core/doc/CEditDoc.cpp

+		NULL,
+		lineStride,
+		lineStride * height, 
+		(BYTE*)pvImageBits);


メモ：変換済みビットマップからpixelデータを取り出してDIBSectionのビット領域にコピーしています。
ビット領域のサイズは 4bytes × 幅 × 高さになっています。
細かいことを語ると「猫でも分かる(ry」の１章分くらい説明することがたくさんありますので詳細は略。

berryzplus · 2018-12-08T08:02:50Z

sakura_core/view/CEditView_Paint.cpp

@@ -26,6 +26,7 @@
 #include "StdAfx.h"
 #include <vector>
 #include <limits.h>
+#pragma comment(lib, "Msimg32.lib")


メモ：これも StdAfx.h に移動したいな～。

プリコンパイル済みヘッダに変更が入るといったん全体のビルドが必要になるので抵抗感があります。

自分は何か別の cpp ファイルを１つ作って、#pragma comment(lib, "hoge.lib") の記述はそこに纏めてしまう運用を過去に取っていました。

プロジェクトのプロパティ(Linker, Input)で指定する方法は、VS2005 とかの頃は追加すると全体のビルドが必要になってしまってうげーっと思いましたが VS2017 で試してみるとそんな事無いですね。記憶違いでしょうか…。

#pragma comment(link の仮置き場として最も適切なのはエントリポイントがあるcppだと思います。現状でコモンコントロールの埋め込み命令がstdafx.hにあるので、とりあえずそこに合わせに行くのが妥当かな？と思ってます。

「あるべき姿は winmain.cpp に移動」と言ってます・・・。

あるべきを語り出すと面倒くさいので放置でもいいかな、とかも思ったり。

#pragma というコンパイラ依存の記述に「あるべき場所」が存在するということに納得がいっていません。

StdAfx.h の中身は「ほぼすべてのソースファイルが必要とする基礎的なヘッダファイル」だと理解しています。画像関係は違う気がします。

#pragma というコンパイラ依存の記述に「あるべき場所」が存在するということに納得がいっていません。

#pragma だけならどこでもいいと思います。#pragma comment(link なら話が別です。
実際にリンクが必要なコードと一緒に記述するか、メイン関数を含むファイルに書くべきだと思います。

StdAfx.h の中身は「ほぼすべてのソースファイルが必要とする基礎的なヘッダファイル」だと理解しています。画像関係は違う気がします。

StdAfx.h にはプログラムが必要とするヘッダのうち、滅多に変更されないものを記述します。プログラム内で一度でも利用され、かつ、滅多に変更されないヘッダなら、StdAfx.h に指定する意味があります。反対に、わずかでも変更される余地のあるヘッダは StdAfx.h から参照すべきではありません。

たくさんのソースコードで参照されるかどうかは関係ないと思います。
https://docs.microsoft.com/he-il/cpp/build/reference/creating-precompiled-header-files?view=vs-2017

#pragma comment(lib, "Msimg32.lib") 等の記述場所ですが、エントリポイントがある cpp ファイルに記述するのが適切なのかどうか自分には分かりませんが、どこかのファイルにまとめて記述するのは有りだと思います。StdAfx.h は変更すると全体のビルドが発生するので抵抗感がありますが…。

例えば、Msimg32.lib を追加した理由は AlphaBlend 関数の為ですがこの関数を複数の cpp ファイルに今後記述するかもしれないのでそうなった場合にじゃあどっちに #pragma comment(lib, "Msimg32.lib") を書くべきなのか、とか考えると結論が出しにくいと思うので。

Stdafx.h 中に記述されているマニフェストの依存関係指定ですが、Visual Studio 2005 から使えるようになったみたいですね。

VisualStudio 2018 でMFCアプリを新規作成したところ下記の記述が Stdafx.h に入る事を確認しました。

#ifdef _UNICODE #if defined _M_IX86 #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"") #elif defined _M_X64 #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"") #else #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"") #endif #endif

なお以下がサクラエディタの Stdafx.h ファイル中の記述です。

#if defined _M_IX86 #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"") #elif defined _M_IA64 #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='ia64' publicKeyToken='6595b64144ccf1df' language='*'\"") #elif defined _M_X64 #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"") #else #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"") #endif

Intel の Itanium プロセッサはそもそも誰も動作確認していないので記述を打ち切って良いと思います。

https://blogs.msdn.microsoft.com/oldnewthing/20070531-00/?p=26623

に書かれてましたがそもそも processorArchitecture はワイルドカード指定で良いみたいです。

#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")

そして Stdafx.h ファイルでなくても問題無いので、今後 #pragma comment(linker, .... の記述が増える事を考えると将来的に Stdafx.h から別のファイルに移動しても良いかも知れないと思いました。ただ Stdafx.h ファイルをいじると全体のビルドが必要になるので、Stdafx.h ファイルに何か記述を追加する必要が生じた時についでに、でも良いと思います。全体のビルドもサクラエディタはそこまで重いとは思いませんが…。

Stdafx.h 中に記述されているマニフェストの依存関係指定ですが、Visual Studio 2005 から使えるようになったみたいですね。

マニュフェスト自体が vista 以降だった気が。
windows xp もサービスパックを当てればマニュフェストを認識できますが。

Intel の Itanium プロセッサはそもそも誰も動作確認していないので記述を打ち切って良いと思います。

これは提案すれば反対する人いないと思います。
IA64アーキテクチャで動かすことは誰も想定してないはず。
これってどういうものですか？って質問はあるかもですが（笑

https://blogs.msdn.microsoft.com/oldnewthing/20070531-00/?p=26623

に書かれてましたがそもそも processorArchitecture はワイルドカード指定で良いみたいです。

一度どこかで話題に出た気がします。

ワイルドカードを指定した場合には、
プログラム起動時に「Win32サブシステム」が妥当なアーキテクチャに読み替えてくれます。
この読み替えのオーバーヘッドがどれくらいあるかは分かりません。
指定できるものは指定したままにしよう、と提案した記憶があります。

#pragma comment(linker と #pragma comment(link は別物です。

#pragma comment(linker ・・・ソースコードにリンカオプションを埋め込む
#pragma comment(link ・・・ソースコードに依存ライブラリ指定を埋め込む

いずれもプロジェクト設定で指定できますが、プリプロセッサで内容を変えられるのが #pragma を使うメリットです。

リンカオプションは矛盾した指定をしてしまう可能性があるので多用すべきでない気がします。
どこか一か所にまとめて記述するようにしたら矛盾させるリスクを下げられるんじゃないかと思っています。
これは根拠がある話ではありません。なんとなく、そう考えているだけです。

berryzplus · 2018-12-08T08:05:24Z

sakura_core/view/CEditView_Paint.cpp

@@ -198,6 +199,8 @@ void CEditView::DrawBackImage(HDC hdc, RECT& rcPaint, HDC hdcBgImg)
 #else
 	CTypeSupport cTextType(this,COLORIDX_TEXT);
 	COLORREF colorOld = ::SetBkColor(hdc, cTextType.GetBackColor());
+	MyFillRect(hdc, rcPaint);


メモ： MyFillRect は指定された矩形を現在の背景色で塗り潰す独自関数です。
透過実装を行うなら、この辺を中心に見直しかけることになると思います。

GDI 使った描画から Direct2D 使った描画に切替がぼちぼち必要ですね。

切替というかGdi描画機構は可能な限り残したいなぁ・・・と思ってます。

テキスト描画方法の変更に着手できるのは年明け以降になる見込みですが、直接directwrite実装に移行させたい所存です。

直接 GDI や Direct2D, DirectWrite の API を叩かないでクラスで包んでから呼び出すようにするのが良いと思いますが、空想と現実の間には距離がありますね。要求するニーズを満たすクラスの設計も実装も大変だし面倒だし。

berryzplus · 2018-12-08T08:14:23Z

sakura_core/doc/CEditDoc.cpp

+		(BYTE*)pvImageBits);
+	if( FAILED(hr) ){
+		::DeleteObject(m_hBackImg);
+		m_hBackImg = NULL;


メモ：ビット領域をコピーできなくても、CreateDIBSectionで作ったビットマップは削除が必要です。

beru · 2018-12-08T10:59:42Z

Review ありがとうございました。Merge します。もし問題が見つかったら別PRで対処します。

Windows Imaging Component を使って背景画像を読み込み、透過描画対応

WICを使って背景画像を読み込むように変更

9572c31

背景画像のファイルパスを指定するファイルダイアログの拡張子フィルタに *.png を追加背景画像の描画処理で透過色対応

beru added the enhancement ■機能追加 label Dec 6, 2018

エラー処理の記述漏れ対応

bd179aa

arigayas mentioned this pull request Dec 7, 2018

次期リリース機能選定 #431

Closed

2 tasks

API関数 AlphaBlend は premultiplied alpha な入力の仕様なのでそれに合わせる

d07e105

MinGW対応

a4045f0

MSYS2を入れた後に下記のパッケージをインストールする必要が有るようだ。(´;ω;`) mingw-w64-x86_64-headers-git mingw-w64-x86_64-crt

MinGW対応

070d76a

beru mentioned this pull request Dec 7, 2018

背景画像に対して透過効果を出来るようにして欲しいです #665

Closed

arigayas mentioned this pull request Dec 8, 2018

開発中のバージョン表記について #685

Closed

berryzplus approved these changes Dec 8, 2018

View reviewed changes

beru merged commit 1046936 into sakura-editor:master Dec 8, 2018

beru mentioned this pull request Dec 10, 2018

エディト領域のウィンドウの透過表示 #691

Open

berryzplus mentioned this pull request Dec 31, 2018

コマンドアイコンの編集を簡略化できないか検討する #733

Open

m-tmatma added this to the next release milestone Feb 3, 2019

HoppingTappy pushed a commit to HoppingTappy/sakura that referenced this pull request Jun 11, 2019

Merge pull request sakura-editor#683 from beru/BackImg_WIC

c6df4e5

Windows Imaging Component を使って背景画像を読み込み、透過描画対応

Windows Imaging Component を使って背景画像を読み込み、透過描画対応 #683

Windows Imaging Component を使って背景画像を読み込み、透過描画対応 #683

Conversation

beru commented Dec 6, 2018 • edited Loading

透過色対応の表示例

テキストの背景色を白にした場合

テキストの背景色を黒にした場合

テキストの背景色を緑にした場合

arigayas commented Dec 6, 2018

行番号のない赤枠の部分は画像が無い方がスマートに見えるのですがいかがでしょうか？

berryzplus commented Dec 7, 2018 • edited Loading

arigayas commented Dec 7, 2018

berryzplus commented Dec 7, 2018

berryzplus commented Dec 7, 2018

m-tmatma commented Dec 7, 2018

m-tmatma commented Dec 7, 2018

berryzplus commented Dec 7, 2018

beru commented Dec 7, 2018

berryzplus commented Dec 7, 2018

beru commented Dec 7, 2018 • edited Loading

行番号のない赤枠の部分は画像が無い方がスマートに見えるのですがいかがでしょうか？

beru commented Dec 7, 2018

berryzplus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

レビューコメントではないですが

beru Dec 8, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beru Dec 8, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

berryzplus Dec 8, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beru commented Dec 8, 2018

beru commented Dec 6, 2018 •

edited

Loading

berryzplus commented Dec 7, 2018 •

edited

Loading

beru commented Dec 7, 2018 •

edited

Loading

beru Dec 8, 2018 •

edited

Loading

beru Dec 8, 2018 •

edited

Loading

berryzplus Dec 8, 2018 •

edited

Loading